hp at redhat.com
Thu Apr 12 15:34:06 PDT 2007
David Zeuthen wrote:
> We can be smart about this; the bus just needs to notify servers when
> someone adds a match rule. So if there are no matches for the signal
> org.fd.Properties.Changed() on /org/fd/SomeService/blah, the owner of
> that object just avoids sending out a signal. The bus can notify servers
> asynchronously and would also provide a ShouldSendOutchange() method for
Hmm, maybe. I can imagine it is a little hard to figure out whether one
of the match rules would apply, though; e.g. when dbus-monitor installs
its "everything" match rule, does the bus suddenly tell every object to
send every change notification?
We could have some kind of "special" match rule flag or say that only
certain kinds of match rule lead to property change notification, I
suppose. Maybe the property-changed signal is special-cased in the match
rule stuff and has to be matched via a special kind of rule.
> You might want to use the signature "sbbv" for Changed() too so it looks
> like this
> Changed(STRING propNAME, BOOL wasAdded, BOOL wasRemoved, VARIANT value)
Right now the properties are in the introspection xml in theory right,
so they can't be added/removed exactly, only change value...
dynamically-changing interface specs are going to confuse most bindings ;-)
I've debated a bit whether Changed would include the value; this came up
as long ago as when designing gconf. I believe gconf does include it.
The advantage of including it is avoiding another round trip, the
disadvantage is that if nobody cares about the change notification,
you've done potentially a lot of work for no reason. In combination with
the idea of only sending notifications if a match rule exists, it could
There's also Thiago's point that e.g. in C++ there just is not a way to
do change notification on properties, though we could adapt to that by
saying that the change notification is in a separate optional interface.
I suppose we could have a couple of standard interfaces, one where
individual properties result in notification, and one where a change to
any property results in a "whole object has now changed!" notification.
(The purpose of that is to allow changing a lot of properties then
emitting a single signal.)
It's also possible to have a ManyChanged signal that includes an array
of property names or a dict of name-value pairs.
Pretty big can of worms overall. Maybe we should step back and look at
some actual ad hoc solutions people are using already?
More information about the dbus