[Telepathy] Account and AccountManager objects

[Xavier Claessens]

2008/1/25, Simon McVittie <simon.mcvittie at collabora.co.uk>:
>
> -----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


I vote for per (CM, protocol) pair.

* 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


Also a localized description text?

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


I think it could just provide an icon name and if it's not available in the
icon theme it's up to the UI to make a choice based on CM/Protocol.

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-----
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/telepathy/attachments/20080125/b9ac8712/attachment.htm