[RFC] dbus-python API (re)definition

Matthew Johnson dbus at matthew.ath.cx
Tue Sep 5 16:37:49 PDT 2006

Hash: SHA1

On Tue, 5 Sep 2006, Havoc Pennington wrote:

>> (And indeed: would you mind commenting on whether objects changing their
>> supported interfaces during their lifetime is a supported operation, or
>> whether a given object-path on a given unique name should always keep
>> the same interfaces?)
> I don't think it's really a good idea (many sane remote apps would be 
> confused by it) but there's nothing in the lidbus library or protocol that 
> does or could prevent it from happening. If for some reason someone was 
> confident their object users would be OK with this, due to nature of the API, 
> control over code using the object, or whatever, then I don't think there's 
> any reason people can't do this.

I can think of times where it might happen; I think it depends what you
mean by `lifetime of the object'. If you support un-exporting objects
I'd expect you could export an object on a particular path, un-export in
and then export a different one. For example I can imagine an
application which dynamically changes what objects it has on request and
could have them created and deleted remotely. The _object_ won't change
over it's lifetime, but that's not the same as the lifetime of the

If this were the case though, I'd wouldn't expect a proxy to work over
the change, the clients would all be notified (or have requested) the
object deletion, so would have registered new proxies.

As a side point, I don't think just saying 'there's no technical reason
in libdbus that it couldn't be done' is good enough. D-Bus is
object-oriented, whereas libdbus is message oriented. There are
definitely some things which you can technically do with libdbus which
we definitely want to say are not supported in D-Bus. For example
replying to methods with a different type or number of return values
each time is definitely not supported in D-Bus, but you can technically
do it with libdbus (-:


- -- 
Matthew Johnson
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76


More information about the dbus mailing list