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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
