DBus XPCOM

[Gary Cramblitt]

On Monday 13 November 2006 15:20, Mohamed Attar wrote:
> Hello,
>
> First, I'd like to say the DBus technology is great. Congrats on the
> release of Blue Bird.
>
> I am a student at Seneca College, and my friend and I are trying to
> start or continue a DBus XPCOM project.
>
> My professor, David Humphrey, is teaching an Open Source coarse, and is
> closely involved with the Mozilla crew. http://zenit.senecac.on.ca/wiki
>
> We are planning to start some integration between the two technologies.
> We probably won't be able to finish, but other students from the next
> semesters would most likely carry it on.
>
> We checked out Christophe Nowicki's DBuzilla project. I tried contacting
> him about his project, but I didn't get much info. Looks like the
> project has put on a halt for now.
>
> We, the students, are new to Open Source technologies, so forgive our
> ignorance.
> We are curious as to the direction we should go with this project.
> The DBuzilla projects looks like it implements DBus natively to XPCOM
> objects, but I also see there are many bindings to DBus (GLib and that
> openwengo's DBus-CPP looks interesting).
>
> Does anybody have any recommendations as to how we should wrap XPCOM
> around DBus? Would it be possible/best to use the DBUS-CPP library with
> XPCOM? or must it be done natively (like DBuzilla
> http://www.csquad.org/category/d-bus/)?
>

Just some general thoughts.  D-Bus is not a component system -- it is a 
messaging system.  This means you will need to address the following issues:

1.  Object references.  In D-Bus, objects are referenced indirectly via a Path 
Name, rather than a pointer.  You will need to define a protocol for passing 
your object references across the D-Bus.  If you send many such references, 
you may need a way to "shorten" the names by providing an object reference 
registry and pass integer IDs instead of Path Names.  Some projects are 
proposing to use XAtom for this.

2.  Object lifetime and reference counting.  After passing an object reference 
to another process via D-Bus, how do you know when the object may be 
destroyed?  Typically, as is done in XPCOM, this is managed via reference 
counting.  Trying to do reference counting over D-Bus is challenging.   
Performance could become a big concern.

3.  Threading.  As in the DBuzilla project, threading will be an issue.  This 
will have a big impact on which bindings you choose.

4.  Asynchronous versus Synchronous messaging.  In all likelihood, you will 
want to implement asynchronous messaging, but when combined with managing 
object lifetime, you'll discover that avoiding race conditions will be 
problematic.

These are some of the issues you will encounter.  If you work out solutions, 
I'd be interested in them, as we have similar issues trying to implement the 
Assistive Technology - Service Provider Interface (AT-SPI), which is 
currently CORBA-based, over D-Bus.
-- 
Gary Cramblitt (aka PhantomsDad)