[Telepathy] Standardising Mission Control

[Robert McQueen]

Naba Kumar wrote:
> 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.

Opaque how? By using some kind of IPC mechanism, maybe a D-Bus API?
Excellent plan. :D

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

Yes, or they just use existing D-Bus bindings for whatever language they
are using.

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

Fine, I don't disagree wit any of these. But the main thing is that
however a particular mission control implementation decides to store its
accounts should not be exposed in any mission control client libraries -
they access the accounts via the D-Bus API so that the information is
always available to all clients whatever library or platform they are using.

If we want to allow people to be free choose whether they bind or
reimplement "libmissioncontrol" then the best thing we can do to help
them is make it nothing but a D-Bus wrapper, then the bindings they
already have for D-Bus are already what they need.

Really, I don't see the purpose of *not* just doing all of this via a
D-Bus API. Even in a MC "monoculture" it makes it easier to change how
MC stores stuff without needing to modify any libMC stuff, but it takes
care of abstracting the clients from any particular MC implementation.

> Thanks.
> 
> Regards,
> -Naba

Regards,
Rob