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