Various more changes to dbus-python

Matthew Johnson dbus at
Wed Jan 10 10:28:10 PST 2007

On Wed, 10 Jan 2007, John (J5) Palmieri wrote:

> On Wed, 2007-01-10 at 18:15 +0000, Matthew Johnson wrote:
>> On Wed, 10 Jan 2007, John (J5) Palmieri wrote:
>>> On Wed, 2007-01-10 at 13:31 +0000, Simon McVittie wrote:
>>>> As well as the patch to support switching off introspection in
>>>> get_object and get_object_by_unique_name (thanks Ulisses),
>>> It all looks good except this get_object_by_unique_name method.  Why
>>> can't we just use get_object and look at the input to determine if it is
>>> a unique name?  There actually shouldn't be any difference between
>>> requesting a unique name and regular name.  The only restriction on
>>> unique names is that they must be assigned by the bus and not requested
>>> by the client (i.e. you can not call RequestName on a unique name).
>> It depends on the behavior when a name changes hands. If I get a proxy
>> for and process 1 drops the name and process 2 acquires the
>> name, should my proxy now refer to process 1, process 2 or neither?
>> (More normally when a process exits and then connection again).
>> At least, that's what the equivalent in Java does.
> Unique name is a bad name for this API then.  unique names in D-Bus are
> like ":0.1"  Personally I would just have an optional flag in the
> get_object API called follow_name_changes or something to that effect.

I assume the name was meant to be "associate with unique name rather
than well known name". I call them peer-objects in Java, so you attach
the object to a specific peer, rather than whoever the holder of the
well known name is at the time.


Matthew Johnson

More information about the dbus mailing list