D-BUS implementing DCOP - some minor problems?

[Maksim Orlovich]

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

<snip>
>
> I don't think we should try to map DCOP onto DBUS 1:1. The idea is to
> generate

Please do remember that we rely on overloading extensively in some spots,
though.


>> * 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.
> You
> 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
> some
> 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.