D-BUS implementing DCOP - some minor problems?

[Waldo Bastian]

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

I don't think we should try to map DCOP onto DBUS 1:1. The idea is to generate 
native DBUS calls (from the *.kidl files) instead of DCOP calls in KDE 4 with 
some legacy support for old-style DCOP calls. It wouldn't be possible to make 
calls into DBUS from old-style DCOP code, or make calls into old-style DCOP 
code from DBUS. The only thing we would do would be to wrap old-style DCOP 
calls in some DBUS call and unwrap it at its destination so that old-style 
DCOP code can continue to call other old-style DCOP code.

This has been discussed in some more detail in 
http://lists.kde.org/?t=109646896300003&r=1&w=2
In particular
http://lists.kde.org/?l=kde-core-devel&m=109647704712328&w=2

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

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

> * 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()

Cheers,
Waldo
-- 
bastian-RoXCvvDuEio at public.gmane.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian-IBi9RG/b67k at public.gmane.org  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050125/e067fed3/attachment.sig>