Properties interface additions

[David Zeuthen]

On Wed, 2009-01-28 at 12:35 -0500, Havoc Pennington wrote:
> Hi,
> 
> An overall thing, I think we probably need a binding or two besides
> eggdbus to take a crack at implementing this, before we declare it
> final-final. 

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?

> But step 1 is to get a plan we think is plausible here on
> the list.

Anyway, I'll prepare a new patch against the D-Bus spec so it's
completely clear what we want to change.

> On Wed, Jan 28, 2009 at 12:28 PM, David Zeuthen <david at fubar.dk> wrote:
> > Multiple signals, one for each interface. We could change the Changed()
> > signal to fold this into a single signal.
> 
> I don't know, I think it's asking for trouble to rely on all bindings
> coping well here. 

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

Many bindings, like dbus-python, doesn't even expose D-Bus properties.
Some bindings like dbus-glib only exposes them on the server side.

Anyway, the only difference, AFAICT, if you want to interact with a
service using emits_changed="true" for a property is that you'd have to
connect to the org.fd.DBus.Properties.Changed() signal instead of some
home-grown signal. Then you check the hash table whether the properties
of interest has changed. I'd be surprised if this is a problem for a
given binding.

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

So unless NM is a) rev'ing their D-Bus interface; and b) porting things
over to something like EggDBus; then they won't have to change anything.

IOW, I don't expect stable services (e.g. where D-Bus ABI stability is a
concern) to start using using emits_changed="true".

> > Yeah, that sounds good to me. So it would be
> >
> >  <property name="name" type="s" access="read" emits-changed="true"/>
> 
> I'm not sure the convention is emits-changed vs. emits_changed vs.
> emitsChanged so if there are any precedents there, we should match
> those. Otherwise, looks good.

Yeah, of course, it needs to be an underscore to be valid XML.

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

> Another reason to get some testing on this in various bindings before
> we declare it "finalized"

Right.

     David