[Development] Request for a sandbox area: Replicant

[Thiago Macieira]

Em sex 30 maio 2014, às 22:57:02, Stottlemyer, Brett escreveu:
> I'd like to officially request a sandbox for: Replicant

Hello Brett

I again support the creation of the repository. We'll have to discuss whether 
this can become part of the Qt standard release because of the overlap in 
requirements with QtDBus as well as the Publish & Subscribe framework that 
used to exist in Qt Mobility and is still present in qtsystems.

> What need does this module solve?
> There were a number of reasons that made QtDBus unattractive for my use
> case. 
> 1) Desire to work on Windows as one of the target platforms.  This
> required building the module/dependencies from source, by every developer
> working on the project. 

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

If libdbus-1 is gone, peer-to-peer D-Bus communication should just work on any 
platform that Qt can run, including Windows, without external dependencies. A 
bus-type communication will still require a server: either dbus-daemon or a 
replacement of your choosing.

> 2) Complexity in initialization vs. notification. 
> There did not seem to be a good way to get the desired properties of an
> object and enable change notification from that instant forward.  Getting
> properties and getting notifications are separate requests, so there is the
> possibility of a race condition that would cause the client to be out of
> sync with the server. 

That is correct. I've opposed so far any use of the PropertyChange signal that 
other D-Bus bindings use. The property is very useful for the receiver side, 
as it could get the change notification from the remote. But it's very clumsy 
from the sender side, as you don't know whether there's anyone listening for 
the notifications. Without that piece of information, a generic framework like 
QtDBus could end up spamming the bus with unnecessary signals.

In order to implement it, I will require a counterpart method to enable the 
emission of signals.

The same goes for the proposed ObjectManager interface that would notify of 
the creation and destruction of objects in the service.

> 3) Using QtDBus as an IPC mechanism between multiple
> physical computers does not seem to be a recommended use-case. 

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.

> 4) QtDBus
> makes it easy to incorporate an existing D-Bus implementation (often not in
> Qt) and incorporate it into Qt. However, QtDBus requires a fair amount of
> refactoring if all programs are Qt programs, to marshal to/from D-Bus types
> and connect the event handler.

That is true and there's little we can do about it, until at least C++ comes 
up with a generic reflection mechanism (which will most likely not happen until 
2020) or we provide one ourselves.

However, is the creation of the operator<< and operator>> really that difficult?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center