RFC: More fine-grained D-Bus signals

Marcel Holtmann marcel at holtmann.org
Mon Jul 13 04:23:55 PDT 2009


Hi Josh,

> > > I'm wondering if we can reduce both the amount of noise on the bus and
> > > the number of wake-ups if we give some of the properties, particularly
> > > of the manager, their own changed signal.
> > > 
> > > For example, in the case of carrick, we don't care about connections or
> > > profiles. And if Marcel adds his proposed Technologies property to
> > > Manager then carrick won't care about devices either.
> > > 
> > > The attached patch adds DevicesChanged, ConnectionsChanged and
> > > ProfilesChanged signals and removes the generic PropertyChanged signal
> > > from the associated code paths and also when the state changes,
> > 
> > If I understand correctly your worry is about waking up processes every
> > time any property changes even though they might be interested only in one
> > specific property, right? That shouldn't be a problem since D-Bus supports
> > match rules for specific values of string-type paramters. You could e.g.
> > have match rule like:
> > 
> > "interface=org.moblin.connman.Manager,member=PropertyChanged,arg0=Devices"
> 
> Oh, cool. I hadn't realised this was possible. 
> That's probably because this functionality is not exposed through the
> dbus-glib API afaict.

yes, and that is why dbus-glib sucks.

> > and this would only wake up the process if a PropertyChanged signal for
> > the Devices property gets emitted. Would this take care of the issue
> > you're seeing or was there something else (which I didn't understand) that
> > makes the PropertyChanged signal undesirable?
> 
> I imagine this would be enough, of course it doesn't help anyone using
> dbus-glib (myself included) so I wonder if the fine-grained signals are
> still valid? Or if I just need to man up and use the D-Bus API directly.

The Get* etc. methods and signals have been tried before within BlueZ
and it was a total nightmare for the UI. So we are not going that route
ever again.

I agree with you that dbus-glib users have a problem, but there is no
chance we gonna cripple the API only for a screwed up implementation.

Regards

Marcel




More information about the connman mailing list