org.freedesktop.DBus.Properties.GetAll

[Havoc Pennington]

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
> bootstrapping.

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 
make sense.

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?

Havoc