D-BUS implementing DCOP - some minor problems?

[Waldo Bastian]

On Wednesday 26 January 2005 07:22, David A. Wheeler wrote:
> 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.

I don't think it would matter if someone were to reply to a broadcast, such 
reply would/should just be discarded.

I would like to note that broadcasts were added to DCOP before we had 
DCOP-signals. I think signals are a much better solution than broadcasts 
because they are much more efficient. The downsides of broadcasts are 
basically:

1) It fits poor with general object oriented design to use broadcasts to 
targets like "mozilla-*", what if later on someone starts to use 
"firefox-xxx" as name?
2) Broadcasts to "*" are very bad for system performance, you end up waking up 
all client-processes on the bus. Most of the time you only try to reach a 
subset of clients.
3) You run the risk of calling non-existent methods/objects. This shouldn't be 
a problem in itself but it may cause excessive warning messages. DBUS itself 
should take care not to send error messages back on the bus. (Does it do so 
when NO_REPLY_EXPECTED is set?)

So given the above, and given the fact that clients can create broadcasts 
manually by querying the list of available clients for the rare cases that 
they really  need it, I don't think that having special broadcast support in 
DBUS is required.

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/20050126/769ab9d1/attachment.sig>