[Telepathy] Proposed standard MC API

[Robert McQueen]

Tobias Hunger wrote:
> 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.

Yes, it's broken. The thing that concerns me is that when manipulating
an account object, the MC implementation will do strict verification of
the parameters you're providing - are they of the right type, and valid
parameters, for the CM underlying that account. If you can go elsewhere
(to the profile/protocol manager) and say that actually, all of the MSN
accounts you have are now to be run by a different CM, this means we
could've rendered some accounts parameters invalid. How do we check for,
prevent and fix this?

One idea I had is that whilst the profile manager will have one
preferred manager per protocol (and a heuristic and/or configuration
means to change it), each account once created actually stores the
manager it's associated with at the time of creation, so that even then
if you reconfigure the profile manager, it stays associated with the
same CM.

Then you replace the problem of breaking an unspecified subset of your
accounts with two lesser problems, of "orphaned" accounts whose CM has
been removed, even though another could do the job, and of accounts who
are "left behind" when a better/preferred CM has been nominated to
handle the protocol, but the account refers to the inferior one.

The solution for both of these is similar, which involves examining each
account and seeing whether its parameters are valid on the current
preffered implementation. If they are, the account can be repaired by
updating it to refer to that manager internally. What to do if they're
not, I'm not so sure....

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

Yeah, my mistake. My chance to fix... :)

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

Regards,
Rob