[Telepathy] Analysis of Decibel AccountManager API

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
  hopefully aren't.

* 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
  these.

* 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
  assume this.

* 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
  this).

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").

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFHz9lfWSc8zVUw7HYRArMTAKCjE8Ipy9rFmuQfj0tC3uNQNZ86RQCgroac
Fpvw1GNhuLynbtzRl/Evzc8=
=pMOU
-----END PGP SIGNATURE-----