[Telepathy] Account conditions overengineered

[Alberto Mardegan]

ext telepathy-bounces at lists.freedesktop.org wrote:
> 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.

It's complete, but I'm not convinced that it's simpler than the one I 
was proposing (which didn't include negative conditions, though). BTW, I 
think that Account_Condition_Alternative make sense only within tha 
namespace.

I think that the logic enum fairly complicates the work for the client 
and the deamon. If we think that NOT conditions are useful, then I would 
propose this: every account will have a list of rules, which are OR-ed 
(that is, the account will be able to connect only if at least one of 
them is met); every rule will consist of two arrays of ss 
(Account_Condition as you specified above), one for the conditions that 
must be met, and one (if we really need it) for the conditions that must 
not be met.

This has the same descriptive power as what you proposed: it implements 
alternative conditions just by having more rules, so for example if your 
rule was:

[
  Condition("has_route", "yes"),
  Condition_Rule("essid", "home", Alternative),
  Condition_Rule("essid", "uncle", Alternative),
  Condition_Rule("connection", "phone", Negative),
]

it would result in two rules:

#rule 1:
[
  # positive:
  [
   "has_route": "yes",
   "essid", "home",
  ],
  # negative:
  [
   "connection": "phone",
  ]
]

#rule 2:
[
  # positive:
  [
   "has_route": "yes",
   "essid", "uncle",
  ],
  # negative:
  [
   "connection": "phone",
  ]
]

Which has the disadvantage of taking some more memory, but the advantage 
of being sensibly simpler.
Given the fact that the use-cases for alternative conditions are going 
to be quite limited, I would see anything than a list-based approach to 
be too complicated.

Then, I would also totally eliminate the negative conditions; this would 
cause a loss of expressive power, but I'm not even sure the clients are 
going to need it...

Another thing to keep in mind is that these rules might also be 
specified in the .presets (and maybe also in the .manager) files, so the 
easier they are, the better it is. :-)

In the latter proposal, we could combine them so that the conditions 
specified in the .manager and .presets files will be appended to every 
rule specified in the accounts; and if we allow the manager and presets 
to provide more than one rule, they will be again treated as 
alternatives, hence the account rules will be duplicated for each of 
them. Mmm... I expressed myself awfully, but the concept is not as 
complex as it seems!

Ciao,
   Alberto

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