[RFC] dbus-python API (re)definition

[Jeroen T. Vermeulen]

On Fri, September 1, 2006 00:01, Robert McQueen wrote:

> Client side we also have code in Telepathy which lets you do
> proxy[INTERFACE].Method() to invoke stuff without bothering to keep
> around pointers to seperate interface proxies. That'd be nice to see
> included.

Nice one--that would also solve the existing name clash problems:

 * With array indexing (proxy[IDENTIFIER]), the "identifier" can be an
arbitrary string.

 * There can be no name clashes between interfaces and methods this way,
because interface names must have dots in, and methods must not.

 * There could be a reserved "interface" with an impossible name, e.g.
just the dot, for methods that belong to the proxy rather than the
object: "proxy['.'].connect_to_signal(...)" (or there could be a cast,
which is currently used for interfaces).

 * That would be the perfect place for managing the proxy's relationship
to the object ("just the name" vs. "attached to current instance").

 * When proxies can have methods of their own that don't interfere with
object methods, they can do things that you'd normally have to ask the
bus to do: get connection, get status, introspect.

 * The same trick could be used for the interfaces themselves.


Jeroen