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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
