[Telepathy] Account conditions overengineered

[mikhail.zabaluev at nokia.com]

Hi, 

>-----Original Message-----
>From: telepathy-bounces at lists.freedesktop.org 
>[mailto:telepathy-bounces at lists.freedesktop.org] On Behalf Of 
>ext Alberto Mardegan
>Sent: Friday, February 08, 2008 10:36 AM
>Cc: telepathy at lists.freedesktop.org
>Subject: Re: [Telepathy] Account conditions overengineered
>
>> 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,

I don't think it is; it's meant to retain some benefits of the original proposal: 1) flat structure; 2) relative human-friendliness.

>BTW, I 
>think that Account_Condition_Alternative make sense only within tha 
>namespace.

That's my gut feeling, too.

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

I disagree: you expose the client to the science of expression forms; in the example above, it has to duplicate mandatory conditions in every term in the OR disjunction. Arbitrarily complex expressions are possible, which is problematic with UI representations. With the two-level structure, updates and notifications become either more complex, or less efficient.

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

I don't see the need either, I've added those only for completeness.
The negatives are, in fact, not any harder to evaluate than mandatory rules,
but the UI might have a problem here.

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

That's easy: mandatory_conds and alternative_conds parameters (add blocking_conds if you feel like),
each getting a flat list of condition IDs (BTW, we need to restrict the syntax of condition IDs if we think about storing them in .presets and GConf).

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

I'm wary about such a combination.
Let's have the condition parameters override the presets, as do any other account parameters.

Best regards,
  Mikhail