[Development] QtDBus roadmap

[Roland Winklmeier]

Hi there,

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:
> 	http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBus_CS
> 

<snip>
> 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
awesome.
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?

Roland