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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
