[Telepathy] Account and AccountManager objects

[Simon McVittie]

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

On Mon, 28 Jan 2008 at 16:23:53 +0200, Alberto Mardegan wrote:
> ext Simon McVittie wrote:
> > u (Connection_Presence_Type): Desired status
> >   The status MC is or should be trying to achieve *when this account
> >   is able to connect*.
> 
> What are the possible values for this? Just online/offline?

I was thinking "any value except Unset" actually... the current Nokia UI
has an option for "what status do you want when you go online?", after all,
and on an internet tablet that you're not necessarily paying much
attention to, it may make sense that when you go online, it's with
status Away or Busy by default.

> >   May be set to Offline by the user, to disable accounts.
> 
> I guess you mean "...to disable accounts from connecting automatically".

Sort of - I was thinking that the way to make an account connect, if it
hadn't already connected automatically, would be to call SetDesiredStatus()
or equivalent.

> > b: Able to connect
> [...]
> I agree on all this, but I would also add a separate flag for the cases 
> described in the latter paragraph: the UI needs to know that there is 
> something with the account that has to be fixed. So, an "able to 
> connect" flag to indicate whether the account can be connected now, and 
> another flag that says that the account is wrong/incomplete/"the CM is 
> not installed"/etc., which are all things fixable by the user.

Instead of a boolean, this might make more sense as a list of unmet
requirements, where an empty list means "is OK".

(Obviously, we could choose to optimize this list into a bitfield ... or not.
Whichever makes more sense.)

> I suggest to call the "tags" rather than "groups" (I mean the 
> user-assigned ones). We might want to specify some well-known tags, such 
> as "work", "home", "toilet ;-)", but still leave the possibility to 
> different clients to group them with different criteria.

Ah, here's where it gets interesting...

If the terminology is "tags", an account can "obviously" have multiple tags.
If the terminology is "groups", it's unclear. We shouldn't call this
concept "tags" unless we're prepared to commit to supporting many of
them (which perhaps we should be... I could be persuaded.)

I'm assuming that these tags or groups will be arbitrary strings assigned by
the user - we could suggest "work" or "home", but they're free to use
whatever.

> for instance
> the account mardy.at.work at google.com could have these requirements:
> 
> { "ip-route": True, "ap-name": "work AP" }

Whoa, whoa. ip-route there is clearly a technical requirement (Gabble
*needs* IP), but ap-name looks more like a user preference (you don't *want*
this account to auto-connect unless you're at work). Contradicting your
next paragraph:

> An account with no requirements would be able to connect anytime.
> I wouldn't mix the requirements (IP connectivity, availability of a 
> phone line, bluetooth, VPN,...) with the user preferences about when to 
> connect, which seems to be more fit for a UI: if the user doesn't want 
> to connect the gnome-phone-manager he can either disable the bluetooth, 
> or set the preferred connection status of that account to offline.

(The issue with g-p-m is that (I assume) you can't tell whether the phone
is around or not without polling for it periodically, which kills your
battery life... although as you say, the user can just turn off
Bluetooth to disable it.)

On the other hand, assuming CMs declare their own technical requirements
somehow (either automatically, or just by MC knowing that e.g. the
protocol 'local-xmpp' never needs an Internet connection), we won't really
be able to address the "I only use this when I have a VPN" use case in
an automated way - only the user's third-party VPN GUI addon knows what
VPNs are available, and only the user knows which accounts are VPN-only.
Unless you're suggesting that the VPN GUI tells MC to add a
user-settable tag for each configured VPN, called something like "connect
automatically when vpn.example.com is up"?

Urgh, this is tricky...

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

iD8DBQFHngDXWSc8zVUw7HYRAmxpAJ4ltuzZiJNoxy8E+rgKKs2zECVz4wCfYR0b
LD5rn8hyEub46ZB8t0CpGkc=
=6aqV
-----END PGP SIGNATURE-----