[Development] QtDBus roadmap
roland.m.winklmeier at gmail.com
Mon Jun 9 09:52:30 CEST 2014
this quote originated from "Request for a sandbox area: Replicant", but
I did not want to hijack this discussion for something different.
On 05/31/2014 01:33 AM, Thiago Macieira wrote:
> One of the goals for QtDBus is to replace the need to have libdbus-1
> installed. We discussed this at QtCS last year and we all agreed this is the
> future, but work has not happened. This is required for kdbus support on
> Linux. See the notes from last year:
> Correct, but only because libdbus-1 does not offer native support for
> encryption and authentication. It does offer a "d-tube" functionality, which is
> simply getting and setting the bytes that correspond to one D-Bus message, so
> that the upper layer could send over their preferred communication method. By
> using this, we'd be able to put the bytes over a QSslSocket provided by the
> user and thus execute RPC securely.
> Converting QtDBus to use "d-tube" is one of the steps in getting rid of the
> lidbus-1 dependency altogether. See the QtCS link above.
> Once we get QtDBus independent of libdbus-1, it should be possible to simply
> provide an opened, bidirectional QIODevice* to a QDBusConnection and would do
> the communication for you.
Having a QtDBus connection via an encrypted ssl socket would be super
And here is my question: How far is this libdbus-1 replacement? I have
read the work has not been done yet. Is it because there wasn't the time
to do it or are there any blocking points?
Is there anything I can contribute to and help to get it implemented?
More information about the Development