DBus XPCOM

[Havoc Pennington]

Gary Cramblitt wrote:
>  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.

This is not a good idea imo,

1) relative to everything else happening the size of the object path is 
probably not even measurable as a performance issue - it isn't a large 
fraction of the dbus message, and message size does not make a big 
performance difference anyway unless you're shoveling megabytes of data 
(in which case the megabytes of data presumably are not just object refs)

2) you can use a path like "/abcd" if you like, which is extremely short 
(though I'd advise a namespace instead, even say "/com/example/abcd" is 
plenty short). Or if you want integer IDs in-process then just track 
them and make the object path /com/example/1234 where 1234 = your 
integer id.

3) in real-world performance the X atom will be *much* worse than some 
extra bytes in dbus messages; it will mean talking to the X server (even 
round trips), and there is no way to delete old unused X atoms.

For performance, the first worry should always be round trips, not size 
of messages. Sending and receiving a message involves all sorts of 
parsing, validating, context switching, etc.; this fixed overhead is 
almost all the work. As long as your message is under 1K or so (whatever 
the buffer size libdbus uses, don't remember), the number of read/write 
syscalls will be the minimum number. So shrinking the message will do 
one thing: *very* slightly speed up the memcpy()'s that happen, which 
are not the bottleneck anyway.

> 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.   

s/challenging/totally insane/ (been there done that)

What you want to do here is have explicit lifecycle policies on remote 
objects. Good ones include:
  - stateless. like http, just have calls that don't require keeping
    an object around beyond a single request.
  - leases. Remote object times out and has to be recreated.
  - explicit destroy. Users of a remote object must call a "destroy"
    method.  (Best combined with a remote object implementation that
    tracks when the object owner disappears without destroying, and
    automatically cleans up. Otherwise crashed apps cause leaks. dbus
    is designed to make this possible.)

A frequent version of the third pattern is a register/unregister kind of 
metaphor; to use a given API you must "register" which allocates a set 
of resources specific to you and gives you a "registration ID" for 
referring to those resources. Many web services APIs, such as the 
Facebook one, use a model like this.

You can then either time out registered clients that have not done 
anything lately, or you can monitor their presence on the bus and drop 
their resources if they vanish.

> 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.

D-Bus should give you the tools to avoid races, though as with anything 
asynchronous you have to think about it a little bit. I find it helps a 
lot to avoid recycling resource identifiers. So for example unique bus 
names won't be reused, so you can know there isn't a race where you'll 
suddenly be talking to the wrong process. I would recommend doing 
something similar with any custom object paths.

> 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.

Please post any questions you have and we'll try to help out, btw.

Havoc