[Telepathy] Account and AccountManager objects

[Simon McVittie]

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

On Wed, 23 Jan 2008 at 08:57:13 +0200, Alberto Mardegan wrote:
> ext Simon McVittie wrote:
> > Just what is an account?
> > 
> > - - an independent "identity"
> >   - if I connect to XMPP as smcv at example.com/N810 and smcv at example.com/Laptop,
> >     I think we ought to think of that as one account
> 
>  From a MC POV, they are two different accounts: if you want to have 
> them both connected from the same machine, you'll need 2 MC accounts, 
> whose "resource" parameter will be different.

I'm not saying that they're not conceptually different accounts now, I'm
saying that perhaps they shouldn't be...

Including the resource in the definition of an Account *would* give us the
invariant that you can have at most one Connection to a given Account, which
is perhaps good for everyone's sanity.

On the other hand, in XMPP it's not guaranteed that you'll get the
resource you ask for - if you connect as smcv at example.com/N810 the
server may (and if it's gtalk, will) rename you to
smcv at example.com/N810__5530ec76 or something. So, we can't necessarily
look at a connection and tell which Account it is.

MC currently has the concept of "normalized name". Am I right in saying
this is what you get by inspecting the self-handle? At the moment this
doesn't necessarily give you a string you can pass as 'account' (see
Salut, which has no account parameter, and if it did, it'd take a value like
smcv rather than smcv at laptop); neither does it necessarily give you something
globally unique (see Idle, in which my normalized name is just "smcv"
regardless of whether I'm logged in to OFTC or Freenode) or even
something uniquely identifying a connection (if you're logged on to the
same XMPP account with two different resources, inspecting the
self-handle will produce the same result).

This is very deliberate - in Gabble, we actively don't want to
distinguish between resources for contact handles. If we later support
resources, we want to add extra interfaces to support them, rather than giving
someone's account more than one handle.

Perhaps we need to tighten up the spec wording somewhere to give MC a
guarantee it can use. "The normalized value of the self-handle uniquely
identifies the account" would be nice, although it isn't currently true.

It is rumored that the next version of MSNP will have a resource-like
mechanism for multiple simultaneous logins. I'm not sure what the
backwards compatibility will look like, but I doubt it'll be pretty!

> I agreee with all the rest you wrote. I'd like to emphasize that one 
> important statement that I'd like to be always valid is that a MC 
> account can have at most one Telepathy connection at a time, and that 
> obviously one Tp connection can be bound at most to one account.

Now, this is difficult if we want MC to be able to pick up on existing
Connections, e.g. after a crash, and associate them with an Account (which we
do - the current behaviour of closing all Connections is somewhat unreasonable,
given that you might not be able to get a given Connection back easily
or at all).

Consider this. I have configured XMPP Accounts for smcv at example.com/N810
and smcv at example.com/Test. MC restarts from a crash, and sees an
XMPP Connection for which the inspected self-handle is smcv at example.com,
and the "unique connection name" (which doesn't currently exist, but suppose we
support it later) is smcv at example.com/N810__5530ec76. How does it know
that this is meant to be the first of my Accounts?

The distinction between connections and accounts
================================================

My loose usage of "account" while writing this message (even though I'm
trying to be precise) illustrates a problem with a "0-1 connections per
account, 0-1 accounts per connection" model. smcv at example.com just *is*
an XMPP "account" (or "entity" if you believe the RFC...), however much we
try to redefine the word so that smcv at example.com/N810 is. I'd instead say
that conceptually, smcv at example.com is an account, and smcv at example.com/N810
is a "(potential) connection".

Now, it could be useful for the MC "Accounts" API to be in terms of
PotentialConnections rather than in terms of accounts, but I think it'd
be a misleading use of terminology to call a potential connection an
Account.

When we inspect our own or other people's handles, we also want to get
an account name, not a connection name. This is what Gabble does at the
moment, anyway, and I think it'd be stupid to change that. It's also what Idle
would do if we switched to having normalized handles be like
smcv at irc.freenode.net (and the more I think about that, the more I think
we should make that switch).

So, I'd argue for a model like this (in an ASCII-art entity-relationship
diagram where "o" means "zero or", "-" means "one" and "<" means "one or more"):

                                        CM
                                        |
                                        o
                                        ^
AccountManager ---o< Account -o---o< Connection --o< Channel

It'd be entirely reasonable for the AccountManager API to make it impossible to
start up more than one Connection to the same Account by asking the
AccountManager (and in fact I'd recommend it), but if you connect to the
Account outside MC (possibly multiple times in pathological cases), it should
realise that you've done that and not explode.

I'll try to sketch out a possible API for this model.

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

iD8DBQFHlzUZWSc8zVUw7HYRAvS7AKDdJBNvqNyHc4YOnRNSU3pfI8ltJgCg1DEA
2gcDKzvmDcxyw5k5KUL4uH8=
=/SJ6
-----END PGP SIGNATURE-----