[Bug 24896] Account.Interface.Conditions

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Sep 6 15:12:44 CEST 2010


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

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-06 06:12:44 PDT ---
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.

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



More information about the telepathy-bugs mailing list