Python binding: ProxyObject questions

[John (J5) Palmieri]

On Thu, 2006-08-24 at 14:18 +0700, Jeroen T. Vermeulen wrote:
> Hello everyone,
> 
> I'm working on an "introduction to dbus" document that can hopefully merge
> with the tutorial someday.  (More about that in another post, to keep
> things on-topic and avoid duplication.)
> 
> Here's a question I came across w.r.t. the Python binding: when looking
> for a particular interface of some object you have a proxy to, why can't
> you just get it from the proxy?  It would seem to make more sense to say
> e.g. "proxy.interface(i)" than "bus.Interface(proxy, i)".

I wrote it as a cast, so you cast the proxy to the interface.  The other
way of doing it is proxy.method(dbus_interface="...")

> At first I thought the answer was obvious: the proxy transparently exports
> all members of the dbus object it represents, and we wouldn't want name
> clashes between the proxy's (python) methods and the (dbus) object's
> methods.  But then why does ProxyObject have a (python) method
> connect_to_signal?  Is that a reserved name that objects aren't allowed to
> use, or is there something else going on?

It is a holdover from the way old bindings.  I had a good answer for why
it doesn't clash at one point.  I can't remember it now.  I don't
recommend that API in any case since the service has to be running in
order to connect to the signal.  The python bindings are due for an
overhaul.  Jdahlin wants to change them completely.

> If there are reserved names, or at least if ProxyObject can be one
> (python) member name that can't ever belong to a (dbus) member, then
> perhaps that would be a good place to add (python) members to the proxy
> that aren't (dbus) object members...

I think my thinking was you needed to call that on the proxy object but
could call the remote method via an interface.  Pretty crappy I admit. 

> Finally, a real nitpick: why is this class called ProxyObject? 
> ObjectProxy would make more sense to me, since it represents a proxy to a
> (dbus) object.  ProxyObject seems to make it explicit that objects of this
> class are objects in the Python sense--and that is obvious from the fact
> that it's a Python class in the first place.

No reason.  I never really sat down to design them since we didn't have
many apps using them at the time.  You don't ever use the ProxyObject
symbol directly so it never really came up as an issue.  What I want to
do is sit down with Jdahlin once I can get D-Bus 1.0 out and really hash
out these issues.  I think we are going to break things.  Jdahlin wants
to, and he is the authority when it comes to python bindings.  BTW he
hates the word Proxy.

-- 
John (J5) Palmieri <johnp at redhat.com>