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