[Bug 24896] Account.Interface.Conditions

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Sep 1 10:13:36 CEST 2010


https://bugs.freedesktop.org/show_bug.cgi?id=24896

Senko Rasic <senko at senko.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|telepathy-bugs at lists.freede |senko at senko.net
                   |sktop.org                   |

--- Comment #1 from Senko Rasic <senko at senko.net> 2010-09-01 01:13:36 PDT ---
(Reassigning the bug to myself).

We could have Condition property with type a{sas} - a map from well-known keys
representing "classes of connectivity", to the particular values that should be
matched:

Condition = {
  "wifi": [ <essid>, <essid>, <essid>, ... ],
  "vpn": [ <vpnid>, <vpnid>, ... ]
  "cellular": [ <networkid>, <networkid>, ... ]
}

with a special case saying an empty list matches any id. So, to eg. say, "use
this account only when i'm connected to my work network (either wifi or vpn)",
you could do something like:

Condition = {
  "wifi": [ "MyWorkNetworkESSID" ],
  "vpn": [ "my-work-network-vpn" ]
}

As in the above example, classes would be ORed, ie. any match would suffice.

Assumed we only provide these three classes, "allow on any connection" would be
expressed as:

Condition = {
  "wifi": [],
  "vpn": [],
  "cellular": []
}

To further simplify things and ensure condition rules are forward-compatible
with adding new classes, we could special-case this as:

Condition = {}

(ie. empty ruleset matches everything).

This is pretty expressive, although it cannot do crazy things like "only use
this account if i'm not on wifi network called Foo, but at the same time I'm
using both vpn Bar and cellular Baz networks.' If we ever come to the point
where we need *that*, we can think of something (like inventing new classes
which will be "not-foo", e.g. "not-on-wifi": [...], ...). But IMHO we don't
need to look into the future that far.

I'm not sure how best to express non-identifiable LAN connections, eg. normal
ethernet link; we can perhaps have a "lan" class and always just use '"lan":
[]' as the match..

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list