Various more changes to dbus-python

[Matthew Johnson]

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 org.foo.Bar 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.

Matt

-- 
Matthew Johnson
http://www.matthew.ath.cx/