D-BUS implementing DCOP - some minor problems?

[David A. Wheeler]

I spent a little time comparing the DCOP and D-BUS documents,
to see if DCOP could be re-implemented using D-BUS.
In a very few areas, the current D-BUS draft doesn't seem to currently
support what's needed to reimplement DCOP (which would really
simplify transition if KDE decided to do it), or at least I
wasn't sure.  The problems do look like they'd
be trivial to solve. Here are the potential semantic mismatches
I could find, please let me know if I'm mistaken:

* DCOP method names include not just the name as you'd expect,
   but the parameter list using the local type names.
   For example, "doIt(int)" is treated as a method name in DCOP.
   In contrast, D-BUS doesn't permit parentheses or commas in
   method names -- D-BUS would use "doIt" as the method name.
   Also, note that method names "doIt(uint)" and "doIt(pid_t)"
   are _different_ in DCOP (they're considered completely
   different methods, even if the underlying types sent over
   the wire are the same).  It's not clear if this
   kind of differentiation is actually employed.

   Recipients of a DCOP call DIRECTLY compare for equality against
   these longer strings (e.g., they compare to see if they
   received a call for "doIt(int)")... so DCOP APIs are
   required to provide these longer names to the message receiver.
   That's important, because that means that if D-BUS simply
   strips off the parameters (e.g., "(pid_t)") to create a
   legal D-BUS message name, there's no way on the DCOP
   recipient end to reconstruct the message in a way
   that the recipient will understand it.

   For a simple transition, D-BUS would somehow need to
   have a way to transfer the parameter list types in the message.
   This could be done by relaxing the rules on message names
   (so "doIt(int)" is legal, as well as "doIt").  This would allow
   D-BUS to directly support the same approach used by DCOP.
   Another solution would be to define a new field to capture the
   parameter list ('parms' field "(int)" or whatever), so that
   this DCOP data would be included in the message.
   You _could_ handle this by quietly adding a new parameter in
   the body with this info, but I think that'd be really ugly...
   that kind of info belongs in the header, not the body.

* The DCOP "send" interface doesn't
   indicate whether or not a reply is expected, so it's hard to
   set the relevant D-BUS flag with confidence.
   However, send by itself doesn't block, so it could probably
   just always set NO_REPLY_EXPECTED; the recipient could ignore that
   flag if they really have data to reply.  The problem here is that
   DCOP doesn't provide enough data, but it's not clear that this
   would really cause any trouble.

* DCOP has two different kinds of connectors, "volatile" and
   "non-volatile".  For volatile connections, if a sender
   OR receiver is deleted, the connection is deleted.
   It's not clear to me from the current D-BUS documents
   how signal recipients are selected, so it's hard to
   determine if D-BUS can do enough.
   The DCOP documents seem to imply that signals are only
   sent to a single recipient
   ("It can be connected to _a_ function..."), but I doubt that's
   actually true (if true, that's a very unfortunate limitation
   that D-BUS can get rid of).

* DCOP's "send" can actually do a broadcast to a set of applications,
   e.g., sending to 'konsole-*' will send to all apps called console.
   D-BUS should implement a 'limited broadcast'; I wouldn't be
   surprised if it does, I just don't see anything about it.
   It doesn't appear that "send" should send a signal, because
   it CAN receive replies.
   According to the DCOP documentation "You cannot call() a method
   belonging to an application which has registered with a unique
   numeric id appended to its textual name..." -- if that's true,
   that's an unfortunate weakness in DCOP that D-BUS corrects.
   I suspect I'm misunderstanding something here though.


For the most part, it looks like DCOP could be implemented on
top of D-BUS, which would clearly make a KDE transition to D-BUS
(if that's what KDE decides to do) _much_ easier.
ASYNC calls seem to cleanly map to the NO_REPLY_EXPECTED flag.
Object names don't begin with "/" in calls to the
DCOP API, but the DCOP-to-DBUS binding could insert "/org/kde"
prefixes to objects not beginning with "/" when calling to D-BUS,
and reverse that when sending data back. As noted by Waldo Bastian,
D-BUS has a "more flexible design of DBUS wrt async message
handling and thread support"
(http://lists.freedesktop.org/archives/dbus/2004-October/001665.html),
so many things look 'at least as capable'.

One suggestion: perhaps the D-BUS term "Bus Name" should be changed to
"Application Name" or "Application ID", like DCOP.
I find the DCOP name for this field far easier to understand
and explain. It's also good for explaining and contrasting
DCOP/D-BUS with different mechanisms like CORBA and DCE.

--- David A. Wheeler