[Telepathy] On removing/standardizing .profiles

[Will Thompson]

Regarding https://bugs.freedesktop.org/show_bug.cgi?id=24897, here's a
rough scheme for standardizing the stuff currently only provided by
libmcclient on Maemo 5. tl;dr:

  • Start from Simon's work on Protocol objects with static protocol
    information…
  • …supplemented by keyfiles much like .profiles…
  • …which will be read by TpQt4 and tp-glib directly (rather than via
    MC).

  • Extend Danni's API for External accounts to include external account
    IDs to relate Telepathy accounts to accounts in a foreign DB;

  • Add methods to filter Tp::Accounts by enabled-ness, online-ness,
    capabilities, etc. to Telepathy-Qt4.

Does this sound good? More details below (which I tried and failed to
make much shorter); feedback would be great! Anything missing?

  ---

On Maemo 5, profiles are used for:

  • Predicting the features which will be available when we sign in
    (possible presences, connection features like avatars, etc.);
  • Default connection parameters (such as server: talk.google.com);
  • Artificially limiting capabilities (such as disabling VoIP, even if
    both the protocol and UI technically support it, for regulatory
    reasons etc.);
  • Actions (types of channel request to show in the address book), and
    other UI-/platform-specific data.

The first pair of items are already being partly covered by protocol
objects <https://bugs.freedesktop.org/show_bug.cgi?id=20774>. For most
protocols, this should be enough for the first two points.

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.

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.

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


-- 
Will