<div>2008/1/25, Simon McVittie <<a href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a>>:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> -----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</blockquote><div> I vote for per (CM, protocol) pair. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * 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</blockquote><div> Also a localized description text? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * 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)</blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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. </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  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" </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 <a href="http://www.xmpp.org/extensions/xep-0165.html">http://www.xmpp.org/extensions/xep-0165.html</a>     §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 <a href="mailto:Telepathy@lists.freedesktop.org">Telepathy@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/telepathy">http://lists.freedesktop.org/mailman/listinfo/telepathy </a> </blockquote></div>