From freedesktop-dbus  Wed Jan 26 14:20:37 2005
From: Waldo Bastian <bastian () kde ! org>
Date: Wed, 26 Jan 2005 14:20:37 +0000
To: freedesktop-dbus
Subject: Re: D-BUS implementing DCOP - some minor problems?
Message-Id: <200501261520.41198.bastian () kde ! org>
X-MARC-Message: https://marc.info/?l=freedesktop-dbus&m=117323211627868
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart6776188.r6m85jUJju"

--nextPart6776188.r6m85jUJju
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 repli=
es
>  > 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=
=20
reply would/should just be discarded.

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

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

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

Cheers,
Waldo
=2D-=20
bastian@kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian@suse.com  |   http://www.novell.com/products/desktop/eval.html

--nextPart6776188.r6m85jUJju
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBB96c5N4pvrENfboIRAqqbAKCoKS9dJCXn2nD5I7uAAUOXTIr5bgCfX4Gt
VsoauCZlREJ58gxleoKqDpA=
=Z6IU
-----END PGP SIGNATURE-----

--nextPart6776188.r6m85jUJju--