[Bug 24896] Account.Interface.Conditions

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-01 06:13:52 PDT ---
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).

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