Properties interface enhancements

[Havoc Pennington]

Hi,

Thiago Macieira wrote:
> No, I'm proposing that potential listeners actively make a call to the 
> destination object requesting that signals for the properties be emitted.
> 

If doing this I think it would have to be the "client registration" 
pattern, i.e. have a Request/Unrequest (connect/disconnect?) pair of 
methods, and have the signal-emitting object track the number of 
requests and also who requested, and automatically Unrequest on behalf 
of any client that exits without unrequesting.

Not obvious to me this is a good idea... the annotation so that only 
certain properties emit the signal might be enough?

The thing is, when you need to use the "client registration" pattern, 
perhaps you often want to register and track clients for reasons other 
than only property change notifications. If that's the case, then having 
a property-notification-specific way to do it could just be in the way / 
extra overhead.

Maybe there's some more general design for the "client registration" 
pattern that would also support non-property-related signals, as well as 
enumerating registered clients in the app in order to call methods on 
them or whatever? [1]

I do think bindings should have support for the client registration 
pattern, and maybe this includes some standard interfaces related to it.

Maybe walking through some use cases would be helpful here.

I do think a changed signal which is optionally marked in the 
introspection data is a simple change we could make, that perhaps 
doesn't block on some of these elaborations.

Havoc


[1] by "more general design" maybe something like:
  iface org.freedesktop.ServerObject {
     void RegisterClient(in object_path client_object_path)
     void UnregisterClient(in object_path client_object_path)
  }
where registration implies getting property change notifies and may also 
imply other things, depending on what we're registering for. A binding 
would support tracking registrations, including auto-unregistering 
clients that disconnect, and might automatically (optionally?) only emit 
signals when clients exist or something like that.

Obviously this is somewhat expensive; the reason dbus has the "match 
rules" thing instead of Qt/GTK style "signal connections" is that signal 
connections like this involve quite a bit of overhead in the app, vs. 
always emitting the signal. If you expect there will generally be at 
least one listener, the context switch is inevitable so the match rule 
approach is more efficient. If you expect there will generally be zero 
listeners, the connection/registration thing is more efficient. Also if 
you need connection/registration anyway for some other reason (e.g. the 
server needs to be able to enumerate clients and call methods on them), 
the connection/registration thing is not adding any *extra* overhead.
I don't know. Not clear performance should even be the primary worry here.