[Telepathy] Standardising Mission Control
wstephenson at kde.org
Thu May 10 04:12:22 PDT 2007
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
> > * Standardise the account store format to ease migration between
> > desktop environments and possibly even mobile devices.
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
> > * 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.
More information about the Telepathy