D-BUS implementing DCOP - some minor problems?
David A. Wheeler
Mon Jan 24 21:17:33 PST 2005
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"
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
More information about the dbus