Dbus-cxx 2.0

[Robert Middleton]

I've started preliminary work on dbus-cxx version 2.0, and I would like to solicit some feedback from anybody who is using the library as to what new feature(s) people may be looking for.  This would not be a complete re-write of the code, however it would still be a significant undertaking, as well as (most likely) making the library both ABI and API incompatible, although I expect that most software would be able to use the new version with only a recompilation.

To that end, I've come up with the following list of things to do, in no particular order:

• Convert the build system to CMake instead of autotools(mostly because I don't like autotools, and the current system does have some limitations/errors)
• Update the dependency on libsigc++ to 2.99.10(new API on libsigc++ that uses variadic templates instead of m4).  Note that 2.99.10 is in preparation for a 3.0 libsigc++.  This would also force a minimum version of C++14.
• The changes to libsigc++ would also make the definitions of methods simpler, as dbus-cxx would also use variadic templates at that point and not be limited to only 7 parameters.
• Update defines for DBusCxxPointer, I think these can actually be templated.  Or alternatively remove this macro, as the point of this macro is to switch between smart pointer implementations, which is irrelevant with C++11 and above.
• Better integration with main loop libraries/frameworks, e.g. glib and Qt.  I'm not familiar with glib but I do know enough about Qt to integrate with it.  Is this something that people would like?
• Update xml2cpp tool to output better code and work better.  Some updates to the code generation will have to be done, and the tool needs to have a big refresh.
• Hopefully make it less sensitive to the ordering of the #includes for custom types.  This still needs more investigation.
• Use std::variant for DBus variants(note: this would force C++17)
• Use std::tuple for DBus structs
• Change the exceptions to not throw as shared_ptr - this change was made before 0.7.0 I think.  I can't find it right now, but there was a message at one point about doing this to make it more consistent with the rest of the library.  While that's not entirely false, it's a very strange way to pass errors back to the user.
• Remove all pthread references - this can now be accomplished with standard library classes.
• General code cleanup by removing inline(it's ignored by the compiler anyway) and adding const/constexpr functions.  Also possibly making the DBus enums into 'enum class' for better typesafety.

Is there anything else that people would like / feel needs to be updated?

Timeline for this update would be at the earliest this summer, but realistically probably by the end of the year.

-Robert Middleton

[Kimmy Posey]

Sounds good Robert. Tell me how I can help you.

Also, as I mentioned in a previous post, it would be nice to ditch the GPL.  That thing gives some folks around my campfire the heebeejeebees.  I know you don't own the copyright and I do intend to send Rick a message asking if future versions could be LGPL'd or the like.  However, as you have prior contact with him, he may be more disposed to listen to you as opposed to JustSomeGuy.  The reason I say this is that I have attempted to contact him before, and I didn't get a response.

-KDP

[Nick Burkitt]

Hi Robert.

I think updating the library is a great idea. My $.02 on a few points:

• I'd discourage requiring anything newer than C++11. You risk limiting your audience too much. I agree that the use of variadic templates would be desirable, but it's not important enough to require C++14. Definitely no on std::variant/C++17. Unless you can offer a C++11-only compile option.
  
• I would also (strongly) encourage ditching the underlying DBus implementation (libdbus) in favor of something known to be thread-safe (such as GDbus). I still have problems with the current implementation. I don't know how different the APIs are, but I'd be glad to help.
• Definitely throw something derived from std::exception, not std::shared_ptr.
• One way to reduce order dependencies might be to allow user-defined types to inherit a "translate to/from dbus" interface (abstract class) that declares pure virtual insertion and extraction operators. That way the only type the library needs to know about is the interface itself.
  
• Also, consider hosting the library on github. You'll likely get a lot more traffic, which could result in more contributors.

Please keep us posted on your thoughts and plans.

-Nick

[Robert Middleton]

Nick,

Those are some good points.  Some thoughts that I had:

• Variadic templates are actually part of C++11, so that's a reasonable hard requirement.  C++14 is only for libsigc++, but I'm not sure if the C++14 features are in the headers or not(I'm going to try and build it on Debian 8 to see what happens).  At least according to the documentation, libsigc++ only needs decltype(auto), which has been part of GCC since 4.8(see: https://gcc.gnu.org/projects/cxx-status.html).  I use Debian as my normal dev environment, so if the library can be built with GCC in 'oldstable' release(currently Debian 8) that is a good baseline.  This also probably forces a minimum Ubuntu version of 16.04.  Given that 14.04 only has updates for the next year I am comfortable not supporting that release.
• As for libdbus vs GDbus, if there's a way to have it configurable I would be open to that.  However, I don't think that this would be easy to do.  For the most part, the C++ objects are simply wrappers around the libdbus objects, so it's rather tied to libdbus.
• The user-defined types for transform to/from is a good idea, I hadn't thought of that before.  That would probably make it simpler; I would also be inclined to allow for something similar as to what we have now.
• As for hosting on GitHub, I'm certainly not against having a mirror on GitHub.  It would still be possible to open PRs on GitHub and merge them into the main repo.  I don't seem to actually have permissions to create a git repo on SF, so it's probably time to see if I can contact Rick.  In my experience though, moving to a more visible platform doesn't equate to an increase of help.
• For the variant, I think that we could get away with having both DBus::Variant(like what we have now, except not templated) and having C++17-only code in something like #if __cplusplus >2017.  That way, you could use either the provided DBus variant class or new compilers can use std::variant.  There are some differences between std::variant and boost::variant, so using boost may not be a good way to go depending on how different it is.

-Robert Middleton

--
You received this message because you are subscribed to the Google Groups "Dbus-cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbus-cxx+unsubscribe@googlegroups.com.
To post to this group, send email to dbus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dbus-cxx/de7d78e2-e874-493a-a23b-df0041f57911%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Robert Middleton]

A quick update for anybody who is interested: libsigc++ has just just made some changes that force C++17: https://github.com/libsigcplusplus/libsigcplusplus

So a version 2.0 of dbus-cxx will probably depend on C++17.  However, most of the changes that I have listed on here would be possible to implement without leaving a C++11 world, so my current thought is to support the current implementation as C++11 only for at least the next two years, to give compilers and users time to catch up.  This is not a hard date though, more fixes could come afterwards so that there would be two simultaneous implementations, one targeting C++11 and one targeting C++17.

My current focus is on updating the xml2cpp program, as that has been neglected for a few years at this point and really needs to be able to generate proper code.  If you're curious, I've started on a new project that I plan to use in order to actually generate the C++ code: https://github.com/rm5248/libcppgenerate

One thought for Nick, if you're still having trouble are you sure this is not a dbus-daemon problem?  I came across this earlier today and I wonder if it could explain some of the weird problems that you have mentioned: https://dvdhrm.github.io/rethinking-the-dbus-message-bus/

-Robert Middleton

[Nick Burkitt]

Hi Robert.

I'm pretty sure the problem lies in the libdbus library itself, or rather in the way it's used by dbus-cxx. I have both C++ and Python applications that talk to my server through dbus, and have never seen any kind of problem with the Python apps. They routinely function in situations where the C++ clients consistently fail. I've seen much discussion about the dangers of using libdbus in a multi-threaded design, and I think the problems I'm seeing can be traced to just that. Of course, the server side is still using dbus-cxx, even when talking to Python clients, but the correlation is still there.

It would of course be possible to determine and then follow the requirements for avoiding multi-threaded libdbus issues, and that may be the most practical approach. But I figured I'd present my wish list anyway. :-)

-Nick

[Robert Middleton]

Nick,

That's interesting to hear, since my understanding is that the python bindings are using libdbus as well.  Unless you're using the GLib version, in which case it may be alright.

I'm going to take a rather wild guess here and say that the work that you and I did the other year helped a lot, since the library also will now only create one thread instead of the 2 or 3 that it did before.  Allegedly libdbus should be able to be used in a multi-threaded manner; dbus-cxx will initialize it as threadsafe by default(in dbus-cxx/utility.cpp).  

As for a GLib version, I just did a quick look at the GLib API vs the libdbus API, and it may be feasible to be able to switch between the two implementations.  Some of the APIs are very similar between them.  This will require much more research though to come up with a set of functions that work between both libdbus and GLib/GIO.

-Robert Middleton

[Nick Burkitt]

Hi Robert.

I don't mean to say that libdbus doesn't work, only that there are certain critical design parameters that must be met if you're going to use it. I think our adventures earlier with the dispatcher addressed the right area, but I'm pretty sure it's still not entirely correct. 

For example, the biggest problem I have occurs when one dbus client calls a method in another dbus client, and that client attempts to call a method in the first client from within the message handler. One or both (I don't recall at this point) method calls will time out after 25 seconds. I suspect that's a symptom of using libdbus incorrectly. The dbus mailing list is probably the best source of information on the subject.

-Nick

--
You received this message because you are subscribed to a topic in the Google Groups "Dbus-cxx" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dbus-cxx/vKGRRZncYmY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dbus-cxx+unsubscribe@googlegroups.com.

To post to this group, send email to dbus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dbus-cxx/CAKpcJVZmFGr3mAsub3LSfdVOAPpfJ%3D7sWx7102OvtWWGWrD7Og%40mail.gmail.com.