[Telepathy] Standardising Mission Control

[Robert McQueen]

Alberto Mardegan wrote:
> I take for granted that we all agree on gconf being the place where to 
> store account data (if not, step forward!). 

Step! The point of standardising the MC API is so that programs from
different platforms can all perform the following tasks:
 * see the accounts we have configured
 * find their Connection objects
 * set their presence
 * request channels

If the accounts are stored in gconf, that's GNOME specific and eg a KDE
app wouldn't be able to find the accounts, and most of the other stuff
becomes hard/impossible.

> Under this condition, I 
> don't see any benefit in having a DBus API for managing accounts; 
> speaking of the package I know (mission-control), most of the API 
> required to manage account are not much more than simple setters and 
> getters of gconf data; the only exceptions might be the account creation 
> /deletion functions, which are doing some work more.
> I'm afraid that a DBus API would just be one level of indirection more, 
> and have the only effects of slowing down things.

Given that the gconf accesses are over D-Bus or CORBA anyway, and that
MC can cache account objects when running, I don't see it as any slower
at all. We can make our own D-Bus account objects which would be similar
to the API presented by McAccount, and they become usable from other
languages and platforms. That's the point of Telepathy.

> BTW, I'm not strictly against the idea of introducing it -- but I would 
> see as an addition, not as a replacement of what is already in 
> libmissioncontrol-config.

Nope, I'd have all of the clients use the API, so MC can replace the
storage of accounts later (if for example we make a standardised account
store format later, Nokia MC can move the accounts from gconf to the
standard file, and the D-Bus API won't change).

>>     * Standardise the account store format to ease migration between
>>       desktop environments and possibly even mobile devices.
> 
> Agreed.

This is less of a priority to me than making it possible to standardise
on how accounts are configured and activated via MC, because currently
GNOME has three projects (Empathy, Banter and Colligo) which are all
configuring and launching their accounts and CMs separately, and this
fragmentation means there's no way any of these things can interoperate.

>>     * Avoid monolithic interfaces in favour of smaller ones that deal
>>       with individual roles eg. account management,  unified contacts,
>>       unified presence. Implementations with specific needs can then
>>       concentrate on the features they need to support.
> 
> I guess that here with "interfaces" you are still referring to DBus 
> interfaces.

D-Bus interfaces, or just different D-Bus objects which deal with
different jobs. So you might have a D-Bus object which was like
McAccountManager, McAccount objects, McConnection objects,
McPresenceManager, etc, which all appeared at different bus paths and
had simple API. This is more like how Decibel's API appears, and is a
lot less confusing than having one big object which has
DoStuffWithThing(thing_identifier_string). D-Bus' native thing
identifier strings are object paths. :)

> What we have now in mission-control is only "unified 
> presence"; contacts and account management are left out. About the 
> latter, as I just wrote I don't have a strong opinion in favor of it, 
> while about contacts I am too biased by Nokia's eds-sync to come out 
> with any different idea. :-)

I'd punt on contact unification in the short term, because it depends on
address books which are ferociously platform-specific, and I don't want
the standardised MC API to grow to include an address book abstraction.
We can look at doing that later, but at the moment I'm concerned that
even on one desktop, let alone using apps from different desktops, each
Telepathy-using application fields it's own accounts and connections,
and others can't meaningfully use them. That's a big loss.

> Ciao,
>    Alberto

Regards,
Rob