[Telepathy] Standardising Mission Control

[Naba Kumar]

ext Robert McQueen wrote:
> Naba Kumar wrote:
>> Speaking of gconf usage in mission-control, I have have been thinking 
>> about implementing flexible accounts storage backends (like mentioned at 
>> website). gconf would just be one of the many.
>>
>> That's said, I tend to agree with Alberto that manipulating accounts via 
>> dbus API sounds too far fetched to me. I think what we need is 
>> sufficiently portable library that most mc/client implementations can 
>> use directly (along with the desired storage backend), either directly 
>> in case of compatible languages or via simple language bindings.
> 
> What?! So with flexible accounts storage backends, MC can store accounts
> in different places, and the MC library which everyone is required to
> bind / port / reimplement must also support all of these backends?

No. I think you missed the point. The backends are absolutely opaque to 
whoever is using the mc accounts library. The point, for example, is to 
allow using another method of storage, such as a secure storage if the 
platform has it.

My point about binding was that if someone wants to use the existing  c 
implementation of mc client library in python, it just binds it instead 
of rewriting the library again in python.

> That's absurd. Why not just use a D-Bus API and MC can do whatever it
> wants to store the accounts? The entire point of Telepathy being a D-Bus
> is that we can decouple people from implementations and provide standard
> APIs, so they don't *need* to bind or reimplement things.
> 
This is of course orthogonal to what I said. Having accounts managements 
API in standard MC dbus api does not exclude the possibility to have 
multiple storage methods in mission-control, and also does not exclude 
the possibility that a lazy python programmer would wish to use 
libmissioncontronl via bindings.

Thanks.

Regards,
-Naba