[Telepathy] On removing/standardizing .profiles

[Sjoerd Simons]

On Tue, Jun 01, 2010 at 07:37:43PM +0100, Will Thompson wrote:
> Jabber and SIP are special cases in that there are different sets of
> presets for different services, and we need to be some kind of overlay
> for the third and fourth points anyway.
> 
> So we could add a property to the Account interface containing the
> service name, which might be empty (in which case we're just using the
> "bare" protocol). Then, we store keyfiles in (say)
> /usr/share/telepathy/profiles which are pretty similar to the current
> profiles. Some well-known sections of the keyfile would be described in
> the Telepathy spec, for overriding the Protocol's properties; but they
> could also contain ad-hoc keys for platform-specific extensibility, like
> actions.

I assume the MC backend wouldn't actually save the overlayed version of the
settings, but only the bits that are filled in. Such that one can update the
presets if needed and the various accounts would update themselves?

Currently in empathy we have an issue where we add a workaround in the
hardcoded preset of a given service, but then we need to tell people to
manually apply it or recreate the account :(

Danger here is ofcourse that accounts stop working if you accidentally remove
the preset :/

> Then Tp::Account would grab information on the protocol from the
> Tp::ConnectionManager, overlaying information from
> /usr/share/telepathy/profiles/$account_service_name if present, and
> provide accessors for well-defined stuff like supported statuses. Then
> for access to platform-specific stuff it could just expose a
> Tp::KeyFile.
> 
> MC would also read the profiles for information on capabilities to
> artificially suppress.

Sound sane, small danger if there is a mismatch between what MC thinks is in
the profile file and what Tp-QT4 or Tp-glib think what's in it.

> Relatedly, Danielle Madeley's been working on an External interface[1]
> for MC accounts to indicate which account store they come from; we can
> add a property for the external store's name for the account to that
> interface, and API like:
> 
>     o.fd.T.AccountManager.GetAccountByExternalID (
>       ( s: external account store name (eg. "com.nokia.accounts")
>       , s: external account id
>       ) → o: Telepathy account path
> 
> This lets us allow applications to match up Telepathy and system
> accounts when necessary, although we should generally try to avoid
> applications needing to.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=28197

I've suggested adding a mapping to the interface with storage backend specific
properties. In which case your GetAccountByExternalID would probably take an
a{sv} for finding accounts.. But i wouldn't be too against making it a
just string.

Main rationale there is that if you lookup an up Account by an identifier you
already have specific knowledge about the backend. And it might be natural to
pass one or two properties of non-string types then forcing every backend to
define a string serialisation (e.g. your backend uses integers instead of a
string as an account ID). But again, could be convinced either way :)

  Sjoerd
-- 
Factorials were someone's attempt to make math LOOK exciting.