D-BUS implementing DCOP - some minor problems?

[David A. Wheeler]

[I didn't cross-post this message to kde-core-devel@kde.org,
because I'm not signed up to that list.  If someone thinks it'd be
important to cross-post this posting to them, feel free to do so.
Also, my thanks to both Waldo Bastian and Havoc Pennington for
their detailed replies!!  I now know much more than I did before.]

I wrote:
>>I spent a little time comparing the DCOP and D-BUS documents,
>>to see if DCOP could be re-implemented using D-BUS....

Waldo Bastian replied:
> 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.

Ah! I can imagine how that would help considerably.

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

Okay.  Perhaps a "gateway" could do the translation between D-BUS
and old-style DCOP, if desired, so that D-BUS users could call older
DCOP apps without pulling in DCOP too.

> 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

Thanks for those pointers, I've begun reading.
I think it'd be great to add links to
those threads from the D-BUS FAQ "How does D-BUS differ from DCOP?"
question, as well as documenting that approach.


[Clarification of DCOP "send" omitted -- thanks for the explanation!]


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

Okay; if they're not used, then it's obviously a non-issue.

...
>>   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...
> No, the whole purpose of signals is that it can have muliple listeners.

That's what I suspected.  Thanks!

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

The document "DCOP: Desktop COmmunications Protocol... Extended with DCOP
Signals by Waldo Bastian Feb 19, 2001", in the D-BUS CVS distribution,
file doc/dcop-howto.txt.  But as I said, I suspect I'm misunderstanding
something.  Not being able to call _wildcards_ makes much more sense,
maybe that's what was intended.  I can't imagine why DCOP couldn't
call a particular application instance, that makes no sense to me.

> Cheers,
> Waldo

Thanks!


When I said:
 >>* 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.

Havoc Pennington replied:
 > This is one of the reasons we split the dbus signature into a separate
 > string, so you can get a "method name including signature" by combining
 > the dbus method and dbus signature.
 >
 > The DCOP-like Qt binding would have to convert "doIt(int)" to method
 > "doIt" and signature "i" to send that over dbus, and unconvert on the
 > other end.

I'm sorry, I must not have made myself clear.  Yes, I understand
the new simple D-BUS type signature strings (e.g. "i").  I actually
think that it's pretty slick.  But that wasn't my point.

My point is, in DCOP, two methods different may accept different
C++ types that are implemented by the SAME D-BUS type.
And in DCOP, these two different methods are distinguishable,
because the C++ parameter types' names are considered part of the
method name (that's an odd hack in my way of thinking, though
it's not completely insane).  In D-BUS, the same methods
would not distinguishable unless special actions are made,
because the DCOP types are the same.

E.G., imagine "pid_t" is implemented as an unsigned int.
Thus in DCOP  doIt(pid_t) and doIt(uint) are different, but in D-BUS
they'd _both_ map to a method="doIt", signature="u".

All of this is irrelevant given my new understanding from Waldo Bastian's
message; the approach he describes should deal with it differently.

And I'll also grant that this should be pretty rare.
If you have different methods distinguishable only by the C++ types,
yet are implemented in the same way, you're asking for trouble anyway.
Often you'd want such externally-callable different methods
to have different names. Indeed, as I said:
 >> It's not clear if this
 >> kind of differentiation is actually employed.


When I said:
 >>* 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.

Havoc replied:
 > Doing this for normal method calls breaks dbus entirely, because replies
 > are matched by the serial in the outgoing message. We could perhaps
 > allow it iff NO_REPLY_EXPECTED is set.

Yes, that seems to be the DCOP use... you can send to a wildcard, but
only if there will be no reply.   It seems to me that D-BUS should
permit method calls without returns to do a broadcast, especially
since broadcasts are already built-in for signals.
Lacking a broadcast ability also seems very inefficient for busses;
currently to do a method 'broadcast' (NO_REPLY_EXPECTED), a D-BUS
user has to send #receivers * ( 1 [sender->bus] + 1 [bus->receiver) ]
messages.  If it had a built-in broadcast mechanism, then a broadcast
only requires 1 [sender->bus] + #receivers [bus->receiver] messages.
And it'd be easier too.

In my mind, having some sort of broadcast capability makes sense.

Indeed, this makes me wonder again if there's
a need for in method calls to allow three reply states:
'normal' (please reply), 'NO_REPLY_EXPECTED', and a 'DO_NOT_REPLY' tri-state.
It might be easier for a separate monitor to detect potential
deadlocks if the messages carried more information, including information
on whether or not they're expecting a reply.

 > The implementation most likely would be "all queued owners of a name" so
 > e.g. anyone waiting to own org.freedesktop.TextEditor or org.kde.Konsole
 > (all text editors, all konsoles)
 > An additional flag SEND_TO_QUEUED_OWNERS would cover this I believe.

Yes, I think you're right, as long as NO_REPLY_EXPECTED was required
to be set if SEND_TO_QUEUED_OWNERS is true.  Semantically this is
different than supporting the general-purpose pattern matching
that DCOP supports, though the use case is probably the same.

Anyway, this ability to broadcast one-way calls to a selected set
of recipients seems to be something DCOP has, and D-BUS doesn't,
that really looks useful (and thus probably should be added
to D-BUS).

 >>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.
 >
 > To me "application name" implies "GEdit" rather than "TextEditor" (and
 > like "service", implies that there's only one name per app).

Hmm, fair enough.  Would the term "Application" be any better?
I'm looking for a clearer name than "Bus Name".  After all, you
could easily say that the bus name is usually either "system" or "session"...
but that's not what you mean.


--- David A. Wheeler