[Telepathy] Proposed standard MC API

[Tobias Hunger]

On Thursday 02 August 2007, Robert McQueen wrote:
> Accounts definitely need to be specific to a (manager, protocol) tuple,
> because changing them between managers is wrong (consider the manager
> that supports encryption, with a "require-encryption" option set to TRUE
> by the user, and the manager that doesn't, and MC choosing to use the
> other one... oops). NMC achieves this by using profiles, which specify
> the implementation which should be used, but this is rapidly proving not
> to be scalable because a generic UI like Empathy can't be expected to
> have prior knowledge of all existing connection managers.

I do not like this at all: Replacing a hardly-any-feature-CM with a 
feature-complete-can-do-everything-CM will break accounts, even if the new CM 
can handle them. We can do better.

> Currently I'm leaning to the idea that we should discard the UI-specific
> elements from profiles (or at least make them optional), so that we can
> either ship profiles with CMs, or according to some policy, make sure
> that we create a dynamic profile for each protocol installed so that
> it's usable without extra stuff.

Great idea!

> I think splitting the creation and appearance is a bit odd, it means you
> can leak these half-created account objects which have an object path
> but are otherwise unusable. Are these persistent, do they disappear when
> MC exits, how do you find them again if the client crashes at that
> moment? I'd prefer to see a way of atomically creating them, so that you
> give over all the stuff, and get back an object that's well-formed. This
> might mean providing a profile and the parameters to the creation
> function, and having default empty/disabled values for the other stuff
> like display name, avatar and enabled.

Yeap, this Account-limbo is a really strange concept.

> Whichever API manages the profiles should represent all of the relevant
> information which is derived from overlaying managers, profiles,
> preferences and stuff. It should be in the D-Bus API because it's likely
> that we want to be able to either create profiles on the fly, or have
> them be mutable in some ways. It also helpfully resolves ambiguity about
> when profiles are usable or not, or a client creating and referring to a
> file which MC hasn't seen, etc.

I agree.

> Also I'd rather see the D-Bus API complete enough to allow MC to be used
> fully, otherwise for each MC client library/binding, we force
> reimplementations of XDG search paths, and key-value file parsing, etc,
> and also we break any remote system use-cases before they've even appeared.

I agree again!

Best regards,
Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20070802/711366c8/attachment.pgp