[Telepathy] Account and AccountManager objects

[Simon McVittie]

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

Here are some more attempts to nail down concepts before we get into API
design.

Preset
======

Presets consist of:

* the connection manager to use
* the protocol
* an internal preset name, not for UI (either globally unique or unique
  per (CM, protocol) pair), e.g. gtalk
* parameter defaults (overriding those given by the CM, and overridden
  by those given by the account)

Also worth considering:

* capability info
  - e.g. we know ahead of time that all GTalk accounts have the same server
    features - we can use this to pre-seed the Account's capabilities
  - CM protocol implementations have this too, though

* the displayed name of the preset (localizable somehow)
  - can probably also be used as (part of?) the default displayed name
    for new accounts

* some specified way to select a default icon from a theme:
  e.g. for the gtalk preset (which uses gabble) for the jabber protocol, use
  telepathy-jabber-gabble-gtalk falling back to telepathy-jabber-gabble
  and telepathy-jabber?
  (Should the CM be part of the calculation or not? If so, it should be
  less "important" than the protocol - users care about XMPP vs MSN
  rather than Gabble vs Haze)

Presets should perhaps be exposed as read-only D-Bus objects by MC.

Nokia MC on the Internet Tablets has some extra info, but some of that should
be provided "out of band" by the UIs (e.g. accounts-plugin-gabble
knows how to handle gtalk specially, but that's between it and the
accounts UI).

Account
=======

Stored attributes of an account
- -------------------------------

An Account is uniquely identified in the API by an object path.

s: Displayed name
  User-selected. Account creation UI is responsible for picking a default
  value appropriate for the user's locale - something like
  g_strdup_printf (_("Google Talk (%s)"), my_jid) would be reasonable

u (Connection_Presence_Type): Desired status
  The status MC is or should be trying to achieve *when this account
  is able to connect*.

  May be set to Offline by the user, to disable accounts.

  If you call methods to set this, MC acts on it, but only if the account is
  able to connect.

  (Rationale: if we define this to be "when able to connect", we don't
  have to change it in response to network connectivity - MC can use some
  other mechanism to know which accounts can connect when - and we can
  remember presence across connectivity changes)

  (TODO: Possibly we should store desired presence (the finer-grained
  string one) and status message, per account, too? They probably don't
  make sense globally, but they do make sense per account)

  (TODO: The Nokia UI also has a concept of "whatever you need to do to
  make this account go online, try to make it happen". The API will need
  some sort of support for that - but that should be global or
  group-based convenience API, probably)

s (/connection manager name/ as defined by Tp spec text): CM

s (Protocol): Protocol

s? nullable o?: Preset
  Must be nullable somehow, for what used to be called "vanilla profiles"

a{sv}: CM parameter overrides

(ays): Avatar
  To be uploaded to services that don't have server-stored avatars
  - how can we tell? For the moment we have to assume they don't

s: Nickname
  To be set as an alias once per connect on services that don't have
  server-stored aliases
  - same comments as Avatar
  - terminology change in preparation for splitting the "petname set by me"
    and "nickname set by them" functionality of Aliasing into separate
    PetNames and Nicknames interfaces, which is a change we should make in
    the Telepathy spec - see http://www.xmpp.org/extensions/xep-0165.html
    §2.2 'The Roster as a Petname System'

Also worth considering:

* server capabilities (save capabilities so we know which accounts are
  capable of doing what, even while offline, so UIs can present appropriate
  info)

Transient attributes of an account
- ----------------------------------

Only valid during one MC run; never stored; set by MC in response to the
environment, rather than being user-settable.

b: Able to connect
  Determined dynamically by requirements of the CM/protocol (some
  possibilities: whether we have network connectivity, whether we're
  logged-in to any VPNs, whether avahi-daemon is running...) and whether
  they're met.

  Also, always FALSE if the stored params are no longer enough
  to make the CM happy, or if we have some stored params that the CM
  no longer supports (CM-specific UI code can either perform a migration
  automatically, or require user input; the best a UI can do in the
  absence of CM-specific knowledge is to notify the user and disable the
  account until they've fixed it)

nullable o: Connection (either it has one or it doesn't)

u (Connection_Status): Connection status
  Might not actually need this, it can probably be implicit from whether
  there's a connection, what the presence type is, and whether MC ought
  to be trying to connect?

u (Connection_Presence_Type): Connection presence
  Always Connection_Presence_Type_Offline unless connected.

Account Group
=============

There seem to be two sorts of "group" floating around:

* user-assigned groups (personal and work accounts)

* automatic capability-based grouping (accounts that need a network connection,
  accounts that can run all the time like Salut, accounts that should only try
  to connect when explicitly requested like gnome-phone-manager)

I think the term "account group" should only apply to the user-assigned
groups. Magical groups that the user can't assign should be something
separate; above, I suggest a way to deal with these.

UIs and business rules will tend to be impossibly complex if this isn't
exclusive, so perhaps we can declare that each account is in exactly one
group, defaulting to the special default group "" (which UIs can render as
_("(no group set)") or something).

This can just be a shortcut for setting the "desired status" attribute
on all Accounts in the group, probably? In that way, it's just a special
case of setting status on individual accounts.
-----BEGIN PGP SIGNATURE-----

iD8DBQFHmfWHWSc8zVUw7HYRAvLHAKDGektbrO47fJQWLzQw8ooqo2+JUwCg1yen
w1XVU9NJ6zhlvS20Yim0WWU=
=E9mv
-----END PGP SIGNATURE-----