[Telepathy] Account and AccountManager objects

[Alberto Mardegan]

ext Simon McVittie wrote:
> 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 think it would be easier to have them globally unique, and residing in 
the same directory -- but I'm not going to have a strong opinion about this.

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

Makes sense, but we might want to keep it for later, as it's more like 
an optimisation.

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

I don't think it would be beneficial, IMHO there's nothing wrong with 
applications reading the profiles themselves (or maybe we can provide 
that functionality in a client library). I don't see the advantage of 
using DBus here.

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

Yes.

> Account
> =======
[...]
> 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?

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

I guess you mean "...to disable accounts from connecting automatically".

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

Yes, I would also add this "if you have to go online, do it with this 
presence/message".

[...]
> 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)

Yes, makes sense again.

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

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.

[...]
> 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.

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.

For capability-based grouping we probably need some complex way of 
specifying the match rules.
One possibility would have a list (most of the times consisting of a 
single element) of dictionaries listing the requirements: for instance 
the account mardy.at.work at google.com could have these requirements:

{ "ip-route": True, "ap-name": "work AP" }

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.

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

I think that UIs can just choose to ignore the tags they don't 
recognize, so it's up to them whether to allow multiple groups or not; I 
think that in MC we should allow them. An UI might want to prefix all of 
its tags, so not to mess with other UIs.

> 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.

Yes, one of the few useful things about groups was the 
"SetPresenceOnGroup" API; we could provide presence APIs that work on 
groups.

Ciao,
   Alberto

-- 
http://www.mardy.it <-- Geek in un lingua international!