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

I like the general shape of this proposal. I think there are two related considerations for conditions: basic technical feasibility ("is it worth even trying?"), and user-specific/server-specific policy.

I think it's best to model a connection as a set of "things" we might have, rather than as a single name (so Mission Control would receive a string => string map from its connectivity plugins, and match them against conditions). I've given some straw-man proposals for the conditions that accounts might have (indented), and for what a connectivity source might look like.

Basic technical feasibility
===========================

Accounts for ring/tel need whatever cellular stuff is appropriate. telepathy-ring on N900 is always trivially online, even without a SIM (for emergency calls), so it'd have an empty set of conditions.

    { }

Accounts for protocols with widely available servers (*/jabber, */irc, */sip) need a network route to somewhere where a server might be found, but not necessarily a default route to the Internet. (If you only have a route to 192.168.0.0/24, there might be a jabberd at 192.168.0.42 for all we know.)

    { "network": [] }
    or for CMs lacking IPv6 support,
    { "ipv4": [] }

To be useful, accounts for salut/salut need an interface with multicast capabilities (Ethernet and wireless Ethernet have this, PPP does not); strictly speaking, they could be online all the time like ring/tel, but that would lead to a slightly misleading UI.

    { "multicast": [] }
    or if that's considered to be overengineered, just
    { "network": [] }

Accounts for protocols with centralized servers (*/msn, */skype) need a network route to the Internet, which I think we is best modelled as "we have a default gateway/default route to IPv4 space". (Although, strictly speaking, if we can connect to them via a proxy, we could use them even on an apparently isolated network... in which case treat them like gabble/jabber.)

    { "ipv4-gateway": [] }

Specific policies
=================

This is where specific values for things become useful. You mentioned essid, VPN ID and cellular connection ID as things it might be useful to switch by.

If we make "ipv4-gateway" be the gateway's actual IP address, this is a cheap way to recognise many networks, for advanced users.

Capabilities provided by some sample connectivity
=================================================

I've assumed that "y" is used as a placeholder for "yes, we have this" in pseudo-boolean cases where the actual value isn't useful; we could use anything, perhaps even the empty string.

Wired Ethernet on an isolated IPv4 network (only local services are reachable):

    { "multicast": "y", "ipv4": "y", "network": "y" }

Wired Ethernet with IPv4 and IPv6:

    { "multicast": "y", "ipv4": "y", "ipv6": "y", "network": "y",
      "ipv4-gateway": "1.2.3.4" }

Wireless Ethernet with IPv4 only:

    { "multicast": "y", "ipv4": "y", "network": "y",
      "ipv4-gateway": "192.168.1.1", "essid": "NETGEAR" }

PPP dialup to a cellular provider

    { "ipv4": "y", "network": "y", "ipv4-gateway": "10.6.6.6",
      "cellular": "T-Mobile" }

Alternatively, we could use an a{sv} where the values are limited to the same comparable types that can be used in Client filters (string, all the integer types, and object path).

(In reply to comment #2)
>     { "ipv4": [] }
>     { "multicast": [] }
>     { "ipv4-gateway": [] }

I don't think these are very feasible. I've looked at DBus API provided by NetworkManager as one example, and libconic (the library used to make connectivity checks in Maemo5) as the other example:

* NM interface (http://projects.gnome.org/NetworkManager/developers/spec.html) seems to assume we're on IPv6, there is no (documented) way of checking whether we're on IPv6, and indeed, whether it's possible to be on IPv6 without being on IPv4 at the same time. It can, however, give us the gw info.

* Conic (http://maemo.org/api_refs/5.0/5.0-final/libconic/) can give just basic info about the current connection; AFAICS there's no way to find out gateway ip, or whether we have multicast support or not.

(Multicast support could be assumed based on connection type, e.g. cellular/3g and vpn connections probably don't support it, wlan/ethernet probably do, but of course, if e.g. your laptop is providing wifi hotspot at the conference and routing that through your 3g card, you probably want salut to work on local network even if your default connection (as reported by NM) is 3G).

So, maybe for now we should not spec "multicast". As for IPv4/IPv6, since I don't think we have a practical way of detecting IPv6 stuff, "network" will be basically synonymous with "ipv4", so we could just use "ipv4" instead.

We could use "ipv4-gateway", but I don't think we should use it in profiles to specify "connected to the Internet", because I'm worried that if we can't get the gateway info, these profiles would not work. 

> Capabilities provided by some sample connectivity
> =================================================
> 
> I've assumed that "y" is used as a placeholder for "yes, we have this" in
> pseudo-boolean cases where the actual value isn't useful; we could use
> anything, perhaps even the empty string.

> Alternatively, we could use an a{sv} where the values are limited to the same
> comparable types that can be used in Client filters (string, all the integer
> types, and object path).

I was thinking of connectivity capabilities being a{ss}, and rules being a{sas}, where empty value in the rule means just check for existence of the same key in the capability (without even bothering to check the value). So, any value as the placeholder would do ("" probably being the nicest).

But if I you think a{sv} (which we'd use for both rulesets, so we match the binary values directly, and have "v" be "as" for string list matching) is more elegant, I've no objection to that.

Wrote up the XML based on the discussion.

Git branch (also listed in this bug's URL):
http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/conditions2

Compiled HTML docs:
http://people.freedesktop.org/~senko/telepathy-spec-conditions2/spec/Account_Interface_Conditions.html

Opted for the variants instead of strings, because using the available typing system seemed a bit more elegant than having just strings.

The string => (variant or list) semantics seem a bit strange; I'd anticipated that the type would be a{sav}. That does increase the nesting depth for all the common cases, though, so you're probably right to use a{sv}.

You've described the things in the connectivity map as "properties" but that word is jargon on D-Bus. I suggest "connectivity attribute".

Condition has no change notification. You should either say so explicitly, with rationale, or add change notification and cross-reference it. I'd personally add ConditionChanged(a{sv}: New_Value).

We need to define what subset of the D-Bus type system is available for matching. I propose this:

    The connectivity attributes defined by the account manager MUST have
    types that would be allowed in an _ObserverChannelFilter_ entry
    (string and boolean attributes are expected to be most common).

    The patterns in the Conditions property MUST either have types
    allowed for a connectivity attribute (which matches if the
    attribute is present with value equal to the pattern, using the
    same comparison rules defined in _ObserverChannelFilter_),
    or an array type whose elements could be a connectivity
    attribute (which matches if the attribute is present with a
    value listed in the array, or if the array is empty and the
    attribute is present with any value).

>    *  ipv4 - b: IPv4 network is available

"TRUE if IPv4 network is available, otherwise absent"

>    * ipv4-gateway - s: default IPv4 gateway address

"default IPv4 gateway address, or absent if there is no default gateway"

... and so on

> On the other hand, if the
> +        conditions are not met, the account won't attempt to connect, not even if
> +        requested so.</p>

This behaviour is somewhat annoying in Empathy - if you have NetworkManager but are currently using a connectivity mechanism that it doesn't handle (PPP over Bluetooth is my usual use-case), Empathy will refuse to connect, unless you set the undocumented gconf key to make it ignore NetworkManager altogether.

It might be better to say that if the conditions are not met, then automatic connection, and automatic re-connection attempts, are both disabled, but setting RequestedPresence still works? That's roughly how some other packages' NetworkManager integration works (I believe Firefox and/or Thunderbird do this?) - offline mode is selected when NM says it's offline, but if the user thinks they know better, the app will make a single attempt to connect, just in case it works.

> Example condition matching any connectivity:

Please explicitly say "... matching any, or no, connectivity".

If you don't think some of the current attributes are implementable, please do delete them. Having a simple boolean for "network" would be a good start, if that's all the information we can actually get :-)

(In reply to comment #5)
> The string => (variant or list) semantics seem a bit strange; I'd anticipated
> that the type would be a{sav}. That does increase the nesting depth for all the
> common cases, though, so you're probably right to use a{sv}.

Yeah,  a{sav} makes the booelan matching a bit verbose, and atm boolean matching is the only reason why we'd have variants instead of strings directly, so there's no point in doing it. That was my rationale for going with a{sv} though it's a bit strange.

> You've described the things in the connectivity map as "properties" but that
> word is jargon on D-Bus. I suggest "connectivity attribute".

Ah, thanks. I was searching for a word that would fit better (thought about "capabilities", but cap's don't really have values, they're atoms themselves). I'll update the wording.

> Condition has no change notification. You should either say so explicitly, with
> rationale, or add change notification and cross-reference it. I'd personally
> add ConditionChanged(a{sv}: New_Value).

Agreed, I've added it.

> We need to define what subset of the D-Bus type system is available for
> matching. I propose this:
> 
>     The connectivity attributes defined by the account manager MUST have
>     types that would be allowed in an _ObserverChannelFilter_ entry
>     (string and boolean attributes are expected to be most common).
> 
>     The patterns in the Conditions property MUST either have types
>     allowed for a connectivity attribute (which matches if the
>     attribute is present with value equal to the pattern, using the
>     same comparison rules defined in _ObserverChannelFilter_),
>     or an array type whose elements could be a connectivity
>     attribute (which matches if the attribute is present with a
>     value listed in the array, or if the array is empty and the
>     attribute is present with any value).

Sounds good, copied it verbatim.

> >    *  ipv4 - b: IPv4 network is available
> 
> "TRUE if IPv4 network is available, otherwise absent"
> 
> >    * ipv4-gateway - s: default IPv4 gateway address
> 
> "default IPv4 gateway address, or absent if there is no default gateway"
> 
> ... and so on

Fixed.

> 
> > On the other hand, if the
> > +        conditions are not met, the account won't attempt to connect, not even if
> > +        requested so.</p>
> 
> This behaviour is somewhat annoying in Empathy - if you have NetworkManager but
> are currently using a connectivity mechanism that it doesn't handle (PPP over
> Bluetooth is my usual use-case), Empathy will refuse to connect, unless you set
> the undocumented gconf key to make it ignore NetworkManager altogether.
> 
> It might be better to say that if the conditions are not met, then automatic
> connection, and automatic re-connection attempts, are both disabled, but
> setting RequestedPresence still works? That's roughly how some other packages'
> NetworkManager integration works (I believe Firefox and/or Thunderbird do
> this?) - offline mode is selected when NM says it's offline, but if the user
> thinks they know better, the app will make a single attempt to connect, just in
> case it works.

This is awkward because in some cases, the user really might not want to go online, even if they set the status manually. Consider the case where you have two accounts, WorkAcc and PersonalAcc defined, and WorkAcc should only go online in secure work network (say, vpn or wifi - we conveniently ignore the fact that secure XMPP connections to the server exist :)

You set your presence status manually in Empathy, which makes it set RequestedPresence for all enabled accounts. Your work account is one of them, and although you don't want it go online, it will. In this scheme, there's no way of configuring Empathy+MC to say "I really don't want WorkAccount online now", short of manually disabling it.

In effect, setting that gconf key would have the same effect (all accounts could now go online, including your secret WorkAcc), but at least you would have to conciously set it (and then maybe you'd explicitly want to disable WorkAcc), and you wouldn't hit that case by doing someting as ordinary as setting your presence status in empathy.

(In reply to comment #6)
> If you don't think some of the current attributes are implementable, please do
> delete them. Having a simple boolean for "network" would be a good start, if
> that's all the information we can actually get :-)

I'd ditch ipv4-gateway and multicast for starters; we can add them in a backwards-compatible way later if we think they're needed.

Updated git branch and the HTML docs based on the feedback.

I think this is ready to be a draft. Is anyone working on an implementation?

> +      <p>In cases where it would be beneficial for the user to (temporarily)
> +        override connectivity conditions the user should disable connectivity
> +        checking by means outside of scope of this specification.</p>
...
> +          managed by NM, the user could turn off the checks by configuring the
>            account manager or its connectivity plugins.</p>

This is a bit of a cop-out: Account and AccountManager *are* how you configure the account manager :-)

It seems reasonable to leave this for later definition, but I think having at least some idea how this works is an undraft blocker. It could be as simple as having a method Account.Interface.Connectivity.TryAnyway() you can use to try an unconnected account "just this once".

> +        <li>vpn - s: VPN ID, or absent if not connected to a VPN</li>

Just thought of: what if you're connected to more than one VPN? You might reasonably have an OpenVPN link to your home server and another to your office, for instance?

One possibility would be to set { vpn-openvpn.example.net: True, vpn-vpn.collabora.co.uk: True } or something.

Being connected to more than one WLAN is possible (I think NM might even support it?) but somewhat pathological, so I think we can define 'essid' to be whichever WLAN ESSID your default route goes through. Similar for 'cellular'.

Does this interface support saying ‘only if connected via *any* wlan connection’ or ‘only if connected via *any* cellular connection’?

Oh yes, it does: if you map 'essid' to the empty list. I think this should be called out with explicit examples. Why are essid and friends not defined always to have 'as' values, rather than either 's' or 'as'? By the current wording, I could include { 'network': [True, False] } in the dict, which is meaningless.

Also presumably there should be a Storage_Restriction_Flag for ‘can't change the Connectivity property’?

(In reply to comment #8)
> It seems reasonable to leave this for later definition, but I think having at
> least some idea how this works is an undraft blocker. It could be as simple as
> having a method Account.Interface.Connectivity.TryAnyway() you can use to try
> an unconnected account "just this once".

We could alternatively do the same as what Empathy currently does, and have a GSettings key which you set to tell MC to always assume it's as online as any account needs. Or it could be a property on the AccountManager.

I don't think you regularly want to try just once; you want to try for as long as you're on the train, even if your non-NM-managed GPRS goes up and down and up and down and you keep having to reconnect. The current Empathy behaviour of a persistent hidden switch you flip seems fine.

This hasn't been worked on for 3 years so I'm dropping it back to NEW.

*** Bug 27364 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/44.