signals

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Cheers,
Waldo
- -- 
bastian@kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/a3HCN4pvrENfboIRAgJuAJ44GmnmDYKa2wA38cWw9m0K8LHNaACfXAcr
8d7Q3NeR04LT/2WYk491wD0=
=egwQ
-----END PGP SIGNATURE-----