[Development] QtDBus Improvements

[Andreas Hartmetz]

On Tuesday 30 September 2014 04:49:21 Thiago Macieira wrote:
> On Tuesday 30 September 2014 12:22:26 Daniele E. Domenichelli wrote:
> > Hello all,
> > 
> > 
> > At Qt Contributors Summit 2013 in Bilbao we discussed some
> > improvement> 
> > to QtDBus:
> >  http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBu
> >  s_CS> 
> > I offered to help, but unfortunately I had some important family
> > issues and I couldn't find the time to work on it, since then.
> > Anyway from now on I should have some free time to work on Qt (not
> > much, but better than nothing). Therefore I'm now renewing my
> > offer.
> > 
> > So, are these improvements still in the plan for QtDBus? Has anyone
> > else been working on them? Where can I start?
> 
> Hi Daniele
> 
> Yes, those are still the targets and so far no work has happened.

In fact, some work has happened :)
I'm working on this http://quickgit.kde.org/?p=dferry.git with the goal 
to make it complete enough and easily integratable with QtDBus.

Dferry aims to be a DBus library that is pretty both inside and outside, 
unlike... other products, you know what I mean.
The core marshaller is pretty much done (maybe lacking a fast path for 
arrays of constant sized/simple data elements) and has extensive tests.
Ther I also sacrificed some good practices for speed, within reason - I 
don't think you can get much faster without generating (via templates or 
otherwise) code for particular message types or, well, having an 
unfriendly API.

There are lots of rough corners like classes containing plain old 
pointers that use compiler-generated copy constructors and that kind of 
thing. Memory management is really only as good as the tests and example 
applications require. Those were even Valgrind-clean last time I looked.

Recently I've been looking at multithreading issues and how to implement 
the runtime dynamic loading dance - basically loading the backend 
library if it's there, failing gracefully if it isn't. I didn't find any 
non-tedious way to do it, so far...
About multithreading, I more or less consider it a mistake to use the 
same connection from different threads, but since QtDBus supports it, 
some solution needs to be found.

Help is welcome - obviously the project requires some experience with 
low-level aspects, and since an important goal is for the API to be 
"nice", a sense of style that is at least somewhat compatible with my 
own. I like it simple, short, and understandable. Of course, underdesign 
is also a thing and is not at all what I mean. Finding the primitives 
that work together to make the solution look easy takes time.
Since there is already *a* DBus library if you need one, there's no 
point in making one that isn't better.

Ah yes, I was going on about the backend library? Sorry.
Integration into Qt is also a major piece of work that needs to be done. 
Threading issues and the related routing of incoming signals and replies 
seem to be the main difficulties there.
Also error codes, with the mostly missing error handling in Dferry... I 
think it will be fine to just ignore some of QDBusError's obscure and 
sometimes undocumented error codes, i.e. generate only a few of them for 
the most relevant errors.
Trying to match up error codes and such between APIs can be a **huge** 
time sink and isn't really worth it - been there, done that. Most users 
don't care about the error codes (just success or not) or about two or 
three of them at most. The most common use case for them is debug 
output, which doesn't need to be behavior compatible (it does need to be 
source an binary compatible) and needs human interpretation anyway. 
After the bugs have been fixed, most error codes become irrelevant. 
Actual runtime errors are rare.
Connection closed, malformed arguments (e.g. trying to close a struct 
when there is no struct), {no such, malformed} path / interface / method 
/ property, property read / write not allowed and type signature 
mismatch should cover pretty much all common use cases. Maybe some for 
the most common "convenience proxy methods" that invoke server 
functionality. Those that are actually exposed directly in QtDBus.

Cheers,
Andreas