hi, On Wed, Jan 30, 2008 at 07:48:08PM +0200, Nuutti Kotivuori wrote: > I am a bit confused as to what is actually being asked here.
i have to apologize. i am probably the originator of this discussion on the wrong view on dbus, because mickey and me startet it on irc. i agree, that dbus is async by design for both, method calls and signals. the difference of signals and methods is that signals are broadcasted and are initiated by the server. also they do not follow the request/response paradigma. the benefit of signals for us is that server can issue those without beeing ask. the drawback is that dbus does not allow subscription to signals and delivers signals to all clients (as mickey told me). the point is that i didn't know how to handle request/response decoupeled in glib and python because you don't see dbus's message queue anymore. i did some research for python and found a hint here: http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html#asynchronous-method-implementations that it should be possible but is neither documented nor an example exists. but from dbus.service import method print method.__doc__ shows, how python supports it (see async_callbacks). after all a client that would be interested in a special information could also issue a method call (which is nothing else but sending a request) and wake up to handle the response with the data. this would be nearer at a signal subscription model. are my assumptions correct so far? best regards, michael