[Telepathy] Account and AccountManager objects

[Alberto Mardegan]

ext Simon McVittie wrote:
>>> 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 love bitfields, they remind me of my DNA. ;-)

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

Yes, I think this was also Xavier's initial idea.

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

My ideas were not clear enough to be expressed properly. :-) What I 
meant was basically that the set of requirement to be met for an account 
to be able to connect should not include any logic about how or when to 
connect, but just state a list of conditions to be met: if all those 
match, then the account can attempt to connect.

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

Let's split it (I guess you also meant it, but just to make it clear): 
not "connect automatically when vpn.example.com is up", but "this 
account can be connected only if vpn.example.com is up", which, combined 
to the default presence setting you mentioned in the other mail, would 
in fact allow to realize a behaviour like "connect automatically when 
vpn.example.com is up".
So, summing up:
1) flag "connect automatically when account connectivity is available"
2) presence (+message) to be set when connecting
3) list of dictionaries with the conditions to be met to fire up the 
"connectivity available" event for the account

If (1) is False, then (2) is ignored in this context; but it's still 
used when the user requests a channel when the account is offline.

The contents of the dictionaries in (3) are mostly up to the 
connectivity plugins and the account-editing UI, though in the specs we 
definitely want to list some well-know values.

Also, this connectivity requirements should be allowed to be split in 
the .manager files, .presets and in the account settings, and the result 
should be the sum of all those requirements. For instance, a condition 
like "ip-route" belongs to the gabble CM, while the condition on the VPN 
could be in a .presets file and the access point is something that 
definitely belongs to the account (advanced) settings.

It's taking a lovely shape ;-)
Ciao,
   Alberto

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