Re: [dbus-cplusplus-devel] DBus-C++ feature support

[Andreas V. <li...@br...>]

Am Thu, 4 Dec 2008 16:16:53 -0500 schrieb Schmottlach, Glenn:

> > >
> > > 5) Is there a way to make asynchronous calls from the client-side
> > > (it appears the code generator only produces synchronous proxies).
> > >
> > 'not there yet'
> 
> > I've some support for async calls in the gitorious repo:
> 
> > http://gitorious.org/projects/dbus-cplusplus
> 
> > See here:
> 
> > http://dbus-cplusplus.wiki.sourceforge.net/Introspection+Format
> 
> > It's 'org.freedesktop.DBus.Method.NoReply'.
> 
> > Look in the history of this list for an example how to use it. But
> > currently you've to define the up and down call yourself.
> 
> This isn't what I quite had in mind for asynchronous client support.
> Ideally, the service should be able supply return (out) parameters. I
> don't want to block waiting for the results but instead have some sort
> of callback invoked at a later time (e.g. like handling a signal). The
> tricky part is probably registering the callback with the correct
> signature for the response. Perhaps there would need to be some kind
> of template trickery or use the facilities provided by libsigc++.
> Regardless, your approach seems to only provide a "one-way" function
> call. I truly want the results . . . I just don't want to block
> waiting for them nor do I want to implement a service on the
> client-side that exports a one-way "callback" method on which the
> service can return the response. Is this possible? It appears that
> it's supported in the Glib binding.

For my interface it's perfect. The up and down call is asynchronous. I
simply have to define two separate calls. Currently I do it this way:

--> void calculateRoute (in_param);
<-- void calculateRouteResult (out_param)

I don't like a function with mixed in/out parameters for my interface.
I have a Module.h and a ModuleListener.h generated from two XML files.
Before I tried to implement async methods with in/out parameters. It
was raw working, but not finished. I stopped the work n this feature,
because I currently don't need it. But I think it's not that hard to
implement if you go deeper into dbus-c++.

regards
Andreas