[Bug 24896] Account.Interface.Conditions

[bugzilla-daemon at freedesktop.org]

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

--- Comment #3 from Senko Rasic <senko at senko.net> 2010-09-02 02:04:47 PDT ---
(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.

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