Fri, 19 Sep 2003 23:14:42 +0200
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 19 September 2003 22:40, Havoc Pennington wrote:
> I am leaning toward connections in the bus only, client always sends all
> signal emissions over the wire. Implementation will require libdbus to
> be more aware of whether it's connected to a bus or just a single peer.
That's what we do in DCOP.
> What is a "handler" that you can connect?
In DCOP you can connect signals to DCOP methods. For the application there is
no difference between a normal DCOP call to such method or a call as the
result of a signal.
> Perhaps the bus-side connection could even _store_ a method name, and we
> could say that clients never receive a signal, they only receive method
> calls that have been connected to a signal. That is, we could synthesize
> a message invoking the connected method on the bus side.
Yes, that's what I'm saying :-)
> I lean toward the "C callback" answer though; it seems to me that
> usually you don't want to have to be a D-BUS server/object in order to
> handle notification messages.
I can see benefit in having a client/server separation but for the other part
the requirements are pretty similar to normal remote method calls.
Maybe clients that aren't a server but that do want to handle notifications
can be a server-lite, which is pretty much a regular server but with all the
bits that aren't needed in such scenario either thrown out or disabled.
firstname.lastname@example.org -=|[ SuSE, The Linux Desktop Experts ]|=- email@example.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----