Once more with the dbus/C++ wrapper talk...

[Rick L Vinyard Jr]

P. Durante wrote:
> On 1/28/07, Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> wrote:
>> I would suggest this approach for several reasons:
>>      * dbus-c++ has already demonstrated an approach that satisfies (1)
>> above
>>      * dbus-c++ appears to allow the creation of (2) through the virtual
>> methods of the Dispatcher class
> right, you can subclass DBus::Dispatcher to integrate different kind
> of main loops other than the default (pool() based) one
So, I suppose one of the early evaluation points would be to take a look 
at what a glibmm dispatcher would look like.

>> I think the project directory structure needs to be massaged a bit...
>> i.e. move the headers and source into one directory called dbus-cxx, and
>> use automake's library_includedir to put the files into the right place.
> makes sense, but at the time I started I hadn't enough autofoo to do it
Not a problem. If you want some help, I'd be happy to either provide 
some guidance or do it.

> btw, is there any particular reason for your renaming into -cxx ?
> I've already seen far too many variations on the dbus-{mm|cxx|cpp|c++}
> theme and I'd avoid introducing another name and stick with dbus-c++,
> unless of course there's some consideration about having '+' in
> project names which I ignore
That's exactly it... in the early days, gtkmm was gtk--... I forget the 
actual reason for renaming it gtkmm but Murray probably knows, although 
I think Karl Nelson was at the helm at the time of the renaming. The 
reason I suggested dbus-cxx was due to a comment by Havoc stating that 
he'd prefer to see dbus-cxx to dbus-cpp.

>> It would probably be better to rename the generated server side glue
>> files from <interface>-glue.h to <interface>-server-glue.h or something
>> to indicate that it is a generated server-side stub because of the next
>> item below.
> the code generator does not impose any particular name to the
> generated files so it's mostly a convention, and yes, it's the way to
> go if you're generating both client and server side stubs at the same
> time, right now I use <prefix>-proxy-glue.h and
> <prefix>-adaptor-glue.h to reflect the proxy/adaptor duality used in
> the source code
Excellent. Differentiation is the real point... and naming flexibility 
is even better.

>> I would like to see dbusxx-xml2cpp have the ability to generate a client
>> side stub. The point of this is to simplify client side development. Not
>> only could C++ libraries ship their client side stubs, it would make it
>> possible to ship a generated library of C++ client side stubs for an
>> non-C++ server side implementation as well as simplifying client side
>> stubs for apps.
> good news for you, it does already, I haven't tested the generated
> code personally but I've received positive reports
Excellent. It's always great to hear that a wishlist item is already 
under development. I guess I should have looked more at dbusxx-xml2cpp's 
code.

>> As a specific example, I'll use the hal-listen code from dbus-c++ which
>> relies on the HAL dbus interface:
> I know that example doesn't use generated proxies, but it could (and
> should) be rewritten to use them
That's ok. I was just using it as an example of the need for client stub 
generation, which at the time I didn't think had any work done yet.

>> Anyway, anyone interested???
> of course I am! (unfortunately I don't have a lot of spare time for 
> coding atm)
That's two of us now. Anyone else?