[Telepathy] Analysis of Decibel AccountManager API
simon.mcvittie at collabora.co.uk
Thu Mar 6 03:45:35 PST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Prompted by discussion of the Telepathy.AccountManager API (new in spec
0.17.2) vs the existing Decibel AccountManager API, I've had another
look at Decibel.
Differences between our AccountManager and Decibel's:
* Accounts are objects rather than following the "numeric IDs"
anti-pattern (http://log.ometer.com/2007-05.html). Yes, I know
Telepathy uses numeric handles, and we suffer from it. Our rationale
is that contact handles are (or can be) very numerous. Accounts
* Accounts have a persistent name (this is something that the Maemo
platform needs, and I think it's likely to be useful in general). Decibel
doesn't appear to specify a unique ID for an account, although I can't tell
from the documentation what the "account data" might contain.
* The AccountManager and Account objects are extensible via extra
interfaces, and the "base" API provides a discovery mechanism for
* Accounts are split into "valid" and "invalid" (accounts can
spontaneously become invalid because the CM starts requiring a
previously-optional parameter, or no longer takes a previously-allowed
parameter - this shouldn't happen, but...)
* Accounts are tied to one CM. This is necessary, because each CM has
a different allowed parameter set (and possibly, different semantics for
the same parameter!), so accounts cannot safely migrate between CMs
unless some process has CM-specific knowledge (for both CMs).
If the AccountManager process happens to have appropriate CM-specific
knowledge, it's free to do the migration itself, but the API does not
* The possible properties on an account are explicitly specified, and
are per-interface for extensibility. A distinction is made between CM
parameters (which are just one property), and "the rest".
* Accounts can be set to connect whenever possible with a stored presence,
connect only when needed with a stored presence, or change to a
temporary presence. Decibel appears to only have the equivalents of
CurrentPresence and RequestedPresence, although it's unclear whether
the "intended presence state" is intended to be persistent or not.
* The AccountManager collects connection statuses and attempts to keep
connections online if desired (it's unclear whether Decibel does
Non-technically, for the usual political reasons I think it's better for
attempts at a standard cross-desktop API to be in a cross-desktop and somewhat
implementation-independent namespace (e.g. Telepathy), rather than a
namespace owned by KDE and assigned to a particular implementation
(org.kde.Decibel). This confuses the implementation (Decibel) with
the API, and is a mistake that MissionControl also makes (that's why there is
no mention of "mission control" in the namespacing we're using; we
do not plan to ever release a component called "account manager").
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Telepathy