[Telepathy] Standardising Mission Control

[Will Stephenson]

On Thursday 10 May 2007, Alberto Mardegan said:
> ext Alp Toker wrote:
> > Some possible desirables:
> >
> >     * Client/service separation: Allow for lightweight client
> >       implementations by doing as much work as possible in the service.
> >       This would mean having D-Bus API not only for for accessing
> >       accounts but also for manipulating account details.
>
> I take for granted that we all agree on gconf being the place where to
> store account data (if not, step forward!). 

Step.  That's a big assumption - Telepathy is not the same as gnome.

> 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.

If done right it would be another level of indirection, but I don't see any 
performance requirement in accessing account settings.

> 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.
>
> >     * Standardise the account store format to ease migration between
> >       desktop environments and possibly even mobile devices.
>
> Agreed.

That said I would dispute the need for a standardised account store.  How 
often do real users switch desktop environments? 

1) Standardised MC APIs decouple MC clients and MC implementations ->
A) MC UIs can be replaced keeping same MC (and its account storage impl)

2) Decoupling an MC from its storage implementation ->
B) MCs can be replaced without reentering configuration

IMO A) is a far more frequent and user-gratifying activity than B).  Users 
happily hop in and out of bed with kmail, evolution and Thunderbird and 
reenter their mail settings.  Otherwise, a static config migration tool could 
be provided that would allow B) without the hassle of abstracting gconf and 
kconfig.

> >     * 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.

Agree.

Will