[RFC] dbus-python API (re)definition

[Johan Dahlin]

Simon McVittie wrote:
> As mentioned on #dbus, I plan to re-implement the dbus_bindings part of
> dbus-python using the Python C API rather than Pyrex, and generally sort
> out the dbus-python API. I'm also working on getting some API documentation
> together, using epydoc and reStructuredText.
> 
> Issues I'm aware of at the moment are as follows. If some of these
> already have a solution that I haven't noticed, or if you're aware of
> other issues, please comment.

I don't have time to answer to all of the issues you raised in the mail, but
let me just give you a couple of quick comments.

A couple of weeks ago I started a new set of python bindings for dbus
using ctypes, they can be found here:

  http://svn.async.com.br/cgi-bin/viewcvs.cgi/pydbus/

For checking out the tree using subversion, issue this command:

  svn co svn://svn.async.com.br/pydbus

They should be considered as a prototype at this point, even so  I think
they serve well as a starting point for future work.

I've never used dbus in a real application nor carefully studied the
concepts and the implementation, so I'm warning you that the naming of
methods, classes or modules may not make any sense at all.

* The prototype using ctypes and rewrite the parts that are slow in
  PythonC later, focus on API first and performance and correctness later.

* Namespacing. I've deliberately avoided any kind of aliases in the
  codebase, to make it easier to follow and read the code.
  That will make it possible to connect the name "dbus.bus.SessionBus" to
  a package that's called dbus with a module named bus.py with the class
  SessionBus. Adding aliases makes the end user slightly nicer at the
  cost of adding a layer of indirection.

* I added a couple of parts which makes the introspection on the client
  side more pythonic, it constructs types with methods using the
  introspection  data, and avoids the "casting" of interfaces which is a
  problem the current bindings has. This makes dir() in a client side
  proxy object work as expected.

  I suggest that anyone working on the higher level api should take a closer
  look at some of the python CORBA bindings such as PyORBit which has
  already solved many of the problems (at a technical level) that the dbus
  python bindings suffers from.

* Magic for resolving object paths:

  service = bus.get_service("org.freedesktop.DBus")
  for name in service.org.freedesktop.DBus.ListNames():
     print name

I probably won't have too much time to contribute to the bindings, but here
at least a couple of ideas.

Johan