org.freedesktop.DBus.Properties.GetAll

[David Zeuthen]

On Thu, 2007-04-12 at 18:34 -0400, Havoc Pennington wrote:
> 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.

Yeah, but it's going to be complex no matter what. 

Maybe what we gain is just not worth the cost... I mean, if you have N
servers [1] all emitting notifications they will be woken up _anyway_;
so all this extra complexity would only save us from waking up the bus
daemon.. so the savings would be going from N+1 to N. Probably not worth
the cost.

[1] org.fd.Hal and org.fd.NetworkManager can be rather chatty

> 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 ;-)

Oh, I didn't realize properties are _that_ static; e.g. embedded in the
introspection data; my bad. Now I understand Thiago's comment a lot
better. Sorry.

[...]

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

Yeah, that's what I do in HAL on org.freedesktop.Hal.Device - I don't
include the value though. I also include the number of changes as a
parameter; don't ask why :-)

 <signal name="PropertyModified">
   <arg name="num_updates" type="i"/>
   <arg name="updates" type="a(sbb)"/>
 </signal>

> Pretty big can of worms overall. Maybe we should step back and look at 
> some actual ad hoc solutions people are using already?

In addition, HAL has

    <method name="GetProperty">
      <arg name="key" direction="in" type="s"/>
      <arg name="value" direction="out" type="v"/>
    </method>
    <method name="GetAllProperties">
      <arg name="properties" direction="out" type="a{sv}"/>
    </method>
    <method name="SetProperty">
      <arg name="key" direction="in" type="s"/>
      <arg name="value" direction="in" type="v"/>
    </method>
    <method name="SetMultipleProperties">
      <arg name="properties" direction="in" type="a{sv}"/>
    </method>

as well as convenience SetPropertyInt(), GetPropertyInt() etc. crap.
We're still using raw libdbus sorry; there's still a couple of things
preventing us from using the gobject bindings...

Anyway, the main thinking in HAL is that properties are a lot more
dynamic than on o.fd.DBus.Properties; we don't really know a'priori what
the properties are... this approach has pros and cons; tends to give
more loose ABI guarantees but so far it have worked well for us... we
maintain the syntax/semantics of the properties in a separate document

http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properties

I agree we probably need more than one Properties interface...

     David