Re: Standardising Mission Control

ext Robert McQueen wrote:
> Naba krishna 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
_______________________________________________
Telepathy mailing list
Telepathylists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

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

> 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
_______________________________________________
Telepathy mailing list
Telepathylists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy