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