D-BUS implementing DCOP - some minor problems?
mo85 at cornell.edu
Tue Jan 25 12:49:49 GMT 2005
> On Tuesday 25 January 2005 06:17, David A. Wheeler wrote:
>> 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.
> I don't think we should try to map DCOP onto DBUS 1:1. The idea is to
Please do remember that we rely on overloading extensively in some spots,
>> * 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.
> DCOP "send" doesn't expect a reply by definition, only "call" does.
Those the D-BUS equivalent of answering a DCOPSend would have to be able
to send a dummy/void reply...
The trickier part may be what DCOP inappropriately calls transactions ---
deferred reply, including callback in a client, partly because the
behavior is somewhat complicated, and partly because the D-BUS spec
provides absolutely no semantics.
>> 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.
> Although it seemed a good idea at the time, I don't think that "volatile"
> connections are actually used.
>> 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).
> No, the whole purpose of signals is that it can have muliple listeners.
> connect the signal to a single function at a time, but by connecting it
> multiple times to different functions it will result in multiple functions
> being called.
There is no level for low-level support for signals, anyway. The DCOP ones
just work by making calls to DCOPServer, and the server making calls to
clients, pretty much.
>> * 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.
> Where did you read that? That doesn't make sense, but maybe I'm missing
> context. Maybe it tried to say that you cannot use wildcards (e.g.
> "konsole-*") in a call()
I am guessing here it's referring to the requirement that you use app-pid
even if there is one of app, which was a bit of a change a while back.
More information about the kde-core-devel