D-BUS implementing DCOP - some minor problems?

[Havoc Pennington]

On Tue, 2005-01-25 at 00:17 -0500, David A. Wheeler wrote:
> 
> * 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.

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.

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

Any use of nonbasic types (whether pid_t or QPixmap) would have to be
handled magically by the DCOP-like bindings (converting them to structs
is one possibility)

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

It's not necessary to get this right, NO_REPLY_EXPECTED is purely an
optimization. So if the DCOP binding isn't clear whether a reply is
expected, it should ask for a reply in case someone wanted it.

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

A nonvolatile connection would be a signal match rule that specifies a
well-known bus name, and a volatile connection would be a signal match
rule that specifies a unique connection name.

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

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.
Otherwise, the caller will just have to send a separate message to each
recipient.

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.

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

Havoc