[Telepathy] Account conditions overengineered (was: Account and AccountManager objects)

[mikhail.zabaluev at nokia.com]

Hi,

I've given some thought on how to attain flexibility in account conditions, suitable to cover at least the few use cases I'd like to be able to implement, without pushing the API into the realm of spooky hard theoretical science.

Basically, the proposed change is limited to condition data types, the only other difference is that an account will have a list of rules, rather than just a list of boolean-multiplied condition IDs. The data types are as follows.

Account_Condition: ss
  - A two-part identifier for a condition that can be used to determine availability of an account.
The first string is the namespace identifier, used to distinguish conditions of different nature, or managed by different
client components. The reverse-domain namespacing convention SHOULD be applied when assigning third-party namespace identifiers.
The second string is used to identify the condition within its namespace (e.g. the logical name of a network interface). Conditions that don't need this detail may have this field empty.

Account_Condition_Rule: ssu
  - Each account is associated with a list of condition rules used to determine when a connection shall be established.
The first two members identify the condition in the same way Account_Condition type does (TODO: wildcard rules matching any ID in a namespace). The third is an enum value determining the logic to use when combining all the conditions defined for the account. This field can have the following values:
  Account_Condition_Mandatory - the condition must be met for the account to be connected.
  Account_Condition_Alternative - at least one of the conditions of this type specified for the account (FIXME: in global scope or within the namespace?) must be met for the account to be connected.
  Account_Condition_Negative - the account cannot be connected if the condition is met.

I think this gives a good enough basis for conceivable automatic connectivity configurations.
The clients can also implement arbitrary user-defined tags or groups with this mechanism,
using a dedicated namespace.

Thoughts?

-- 
  Mikhail

>-----Original Message-----
>From: Zabaluev Mikhail (Nokia-D/Helsinki) 
>Sent: Friday, February 01, 2008 2:38 PM
>To: 'ext Simon McVittie'; telepathy at lists.freedesktop.org
>Subject: RE: [Telepathy] Account and AccountManager objects
>
>>-----Original Message-----
>>From: telepathy-bounces at lists.freedesktop.org 
>>[mailto:telepathy-bounces at lists.freedesktop.org] On Behalf Of 
>>ext Simon McVittie
>>Sent: Tuesday, January 29, 2008 3:42 PM
>>To: telepathy at lists.freedesktop.org
>>Subject: Re: [Telepathy] Account and AccountManager objects
>>
>>UpdateAccountConditions (as (Account_Condition[]): Added,
>>                         as (Account_Condition[]): Removed)
>>  Tell the account manager that the account conditions in the 
>set Added
>>  are now met (accounts with those requirements may now 
>>attempt to connect),
>>  and the account conditions in the set Removed are no longer met.
>>
>>  If clients attempt to change automatic account conditions 
>>(as returned by
>>  GetAutomaticConditions), the Account Manager MUST NOT raise 
>>an error, and
>>  MUST change any non-automatic account conditions that are
>>  changed at the same time, but it MAY ignore the attempt to 
>change the
>>  automatic account conditions.
>>
>>GetAccountConditions () -> as (Account_Condition[]): Satisfied
>>  Get a list of account conditions that are currently 
>>satisfied (accounts
>>  whose requirements are all contained in the returned list 
>may attempt
>>  to connect).
>>
>>Signals
>>- -------
>>
>>AccountRequirementsUpdated (as: Provided, as: Not_Provided)
>>  The account requirements in the set Provided are now met; 
>>accounts with
>>  those requirements may now attempt to connect. The account 
>>requirements in
>>  the set Not_Provided are no longer provided.
>
>To cover absolutely all possible use cases, we'd need the 
>whole Boolean algebra over conditions.
>A canonical form could be used to avoid a freeform expression 
>language over DBus. But that
>can be too much to ask.
>
>Best regards,
>  Mikhail
>