Properties interface additions

[Havoc Pennington]

Hi,

On Wed, Jan 28, 2009 at 1:08 PM, David Zeuthen <david at fubar.dk> wrote:
> Sounds OK though I'm concerned this will take some time. Does anyone
> know exactly what bindings, aside from EggDBus, that maps D-Bus
> properties to native properties/attributes/etc?

I guess I was expecting that most do, but maybe none do, I don't really know.

My point was not really about what they do though, but what they could
do. Say you're adding this support to binding xyz, is there a good way
to deal with members with the same name but different interfaces? In
C++ the answer is basically no, for example. I think in Java the
answer is basically no also. In JavaScript it will be awkward. I don't
know.

> Not sure I understand what the bindings would have to cope with.

If you derive from interface A and B that both have member foo in
Java, then the foo has to be the same for both A and B, for example,
if I remember right.

Another example, if the API in JavaScript is like:
 obj.connect('Changed', function() {})

Then which "Changed" is meant, Properties.Changed or Something.Changed
? So you'd have to support scoping the signal name. JavaScript is a
pretty easy case, it's so free-form that whatever can be done, but
C++/Java/C# could be a PITA. I think C# may have facilities for
dealing with this problem though.

Anyway, I just don't see the reason to create the problem;
PropertiesChanged is a fine name and avoids using up perhaps the
single most common signal name ("Changed") in the root object class.

>> Also with NetworkManager already using
>> PropertiesChanged ...
>
> NetworkManager wouldn't have to start using it until they are ready to
> do so. And dbus-glib doesn't do anything useful on the client side for
> properties anyway, in fact you have to do things manually.

Re: NetworkManager, I was just saying it would be nice if the
PropertiesChanged spec matched what NetworkManager already does, since
then they don't have to change anything.

dbus-glib should do things with propeties, imo, to the extent
dbus-glib should exist at all, which of course it shouldn't, but ;-)

>> > Are consumers of introspection XML supposed to cope with a new attribute
>> > popping up? I think they are... the spec doesn't say anything about this
>> > (should we fix that?) but given the X in XML I think they are supposed
>> > to.
>>
>> I would think they are supposed to, but whether they do, I don't know.
>
> Should we amend the spec to say that they should?

Sure.

Havoc