dbus-cplusplus-devel

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

[Schmottlach, G. <gle...@ha...>]

I am considering using the dbus-c++ library in a commercially available
embedded product but I was hoping the project maintainer could answer a
couple of questions.

 

1) Is this project actively being maintained?

 

2) Where is the latest source-tree hosted? It used to be available from
the Freedesktop "git" repository but it appears to no longer exist
there.

 

3) What is the latest/greatest release of the library?

 

4)  Is the library thread-safe? I have seen postings indicating the
reference counting base class is NOT thread-safe. What is the common
pattern for using the library (safely) in a multi-threaded program?

 

5) Is there a way to make asynchronous calls from the client-side (it
appears the code generator only produces synchronous proxies).

 

6) Is there a way to instruct the code generator to generate
asynchronous server-side adaptor methods? This would be similar to
adding the DBus-Glib annotation "org.freedesktop.DBus.GLib.Async" to
methods in the DBus introspection XML file.

 

7) Since dbus-c++ is LGPL, how should changes to the source be fed back
into the project?

 

8) Are there any other caveats or limitations to be aware of with
respect to the binding?

 

9) Does a roadmap for future development exist?

 

I've dabbled with the dbus-c++ library and it appears to be much simpler
and more straight-forward for C++ programs than the more heavy-weight
GLIB binding. I'd really like to use it but its (apparent) lack of
thread-safety and asynchronous support (on both the client and server
sides) seems to prevent it from completely fulfilling its promise as a
mature alternative to the GLIB binding. Do the maintainers have any
intentions of continuing to support and enhance this library, and if
not, are there ways to contribute to its continued development as
required by the LGPL?

 

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

[P. D. <sh...@gm...>]

Hi,

On Tue, Dec 2, 2008 at 9:34 PM, Schmottlach, Glenn
<gle...@ha...> wrote:
> I am considering using the dbus-c++ library in a commercially available
> embedded product but I was hoping the project maintainer could answer a
> couple of questions.
>
>
>
> 1) Is this project actively being maintained?
>
I'm still around keeping an eye on it, but have been busy with my job
and with the demise of openwengo I'm not personally using it for
anything anymore
>
>
> 2) Where is the latest source-tree hosted? It used to be available from the
> Freedesktop "git" repository but it appears to no longer exist there.
>
it sure does, doesn't appear in gitweb for reasons unknown to me.
>
>
> 3) What is the latest/greatest release of the library?
>
I haven't made a release because I'm honestly not confident it would
be a good idea, documentation needs to be written and missing features
need to be implemented or documented as 'not there yet' (see below)
>
>
> 4)  Is the library thread-safe? I have seen postings indicating the
> reference counting base class is NOT thread-safe. What is the common pattern
> for using the library (safely) in a multi-threaded program?
>
libdbus (the reference implementation used by most bindings) doesn't
enforce any threading pattern, so neither should the bindings. if you
experienced problems they should be treated as bugs.
making the internal counter thread safe should just be a matter of
picking one of the many libraries implementing atomic primitives and
integrating it.
>
>
> 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'
>
>
> 6) Is there a way to instruct the code generator to generate asynchronous
> server-side adaptor methods? This would be similar to adding the DBus-Glib
> annotation "org.freedesktop.DBus.GLib.Async" to methods in the DBus
> introspection XML file.
>
same as above, Glib includes a powerful even dispatching mechanism
(among many other things), dbus-c++ is self contained and therefore
much simpler. With some work it's definitely possible.
>
>
> 7) Since dbus-c++ is LGPL, how should changes to the source be fed back into
> the project?
>
I've always gladly accepted patches from anyone, some projects require
explicit copyright transfer to the owner for any modification to be
accepted, but that's really not the case here.
>
>
> 8) Are there any other caveats or limitations to be aware of with respect to
> the binding?
>
not off the top of my head, by I don't know your requirements.
>
>
> 9) Does a roadmap for future development exist?
>
not until someone steps up and writes the code :-)
>
>
> I've dabbled with the dbus-c++ library and it appears to be much simpler and
> more straight-forward for C++ programs than the more heavy-weight GLIB
> binding. I'd really like to use it but its (apparent) lack of thread-safety
> and asynchronous support (on both the client and server sides) seems to
> prevent it from completely fulfilling its promise as a mature alternative to
> the GLIB binding. Do the maintainers have any intentions of continuing to
> support and enhance this library, and if not, are there ways to contribute
> to its continued development as required by the LGPL?
>
My impression is that several people on this mailing list are
interested, of course the code is free and anyone is welcome to add
their enhancements and distribute them.
I'm sure harman has a legal departement which is more qualified than
me to answer about licensing issues, generally speaking you're only
required to make your modifications to the library publicly available
in source code form, either as your own fork or by sending us your
patches (git makes it easy to work both ways).

best regards,
Paolo

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

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

Am Tue, 2 Dec 2008 23:46:37 +0100 schrieb P. Durante:

> libdbus (the reference implementation used by most bindings) doesn't
> enforce any threading pattern, so neither should the bindings. if you
> experienced problems they should be treated as bugs.
> making the internal counter thread safe should just be a matter of
> picking one of the many libraries implementing atomic primitives and
> integrating it.
> >
> >
> > 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.

> > 7) Since dbus-c++ is LGPL, how should changes to the source be fed
> > back into the project?
> >
> I've always gladly accepted patches from anyone, some projects require
> explicit copyright transfer to the owner for any modification to be
> accepted, but that's really not the case here.

The reason why it's not yet in the main branch is that Paolo hasn't
that much time and me also. But now as I've a freedesktop account I
plan to commit some of the non-conflicting changes to the main branch.

Be welcome to test the async code and report problems.

regards
Andreas

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

[Schmottlach, G. <gle...@ha...>]

> >
> > 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.

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