[Bug 24896] Account.Interface.Conditions

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Senko Rasic <senko at senko.net> 2010-09-09 07:38:25 PDT ---
(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.

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