Properties interface additions

[Havoc Pennington]

Hi,

2009/1/14 David Zeuthen <david at fubar.dk>:
> to indicate property changes. Of course this only works if the other end
> is using EggDBus but for the projects I'm working on this happens the
> case. Still, I'd like to propose that we add a Changed() signal to the
> D-Bus specification. I've attached a patch for this. OK to commit?
>

Just looking at NetworkManager 0.7, it has PropertiesChanged rather
than simply Changed; while in theory signals are namespaced by
interface, in many languages it might save some pain to call the
signal PropertiesChanged. "Changed" seems like a common and useful
signal name for all kinds of things.

Is there some way to make it optional to send the new values with the
changed signal? X properties for example do not. The issue is that the
value could be large or large-ish. The basic question for an API
designer would be whether several listeners will almost always want
the value (better to send it), or only 1 or 2 will want it, or usually
nobody wants it, and it's large (better not to send it).

> I've also thought about adding these two methods
>
>  o SetMultiple(IN STRING interface_name, IN DICT:STRING->VARIANT props)
>  o GetAllInterfaces(OUT ARRAY:(STRING, DICT:STRING->VARIANT props))
>
> The former would allow atomically setting multiple properties (e.g. both
> Status and StatusText in an IM interface), the latter would allow for a
> few optimizations (and also cheap introspection of interfaces w/o XML
> parsing).

I don't really understand the second one. It's introspection of
properties only?

SetMultiple seems like it's kind of missing the point of the
Properties interface which is to try to map to some kind of language
properties feature or convention, like javabeans setters/getters or C#
attributes or GObject props or whatever. So if you start having
SetMultiple then it's going to map to a method in a binding, and at
that point you may as well just have SetStatus(in int status, in
string text)

Havoc