Sorry for the formatting guys. Corporate email is Outlook, so I'm manually trying to be polite and bottom post.
> Hello Brett Hi Thiago > 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. Wow. Didn't even know about Publish and Subscribe... >> What need does this module solve? >> 1) Desire to work on Windows as one of the target platforms. ... > > 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 would still be compatible with D-Bus, i.e., still require marshaling, right? Just want to make sure I understand the implications. >> 2) Complexity in initialization vs. notification. > >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. Agreed. There is a lot of complexity under the covers (in Replicant) to make sure each process only receives data once. And because the objects are derived from QObject, I can notify the sender when they are instantiated and destroyed. That allows me to avoid this kind of flooding. But it certainly isn't perfect, and I hope you can find time to take a look at it and help make it better. >> 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. Fair. ATM, I don't either. Google doesn't seem to be as succinct on the point, unfortunately, I think it favors "that's not recommended" links. >> 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. Replicant is Qt only, that is all it tries to be. So it can take advantage of moc. That's one of several reasons why I don't think of Replicant as going "head-to-head" with D-Bus. > However, is the creation of the operator<< and operator>> really that > difficult? I used this to get it working http://techbase.kde.org/Development/Tutorials/D-Bus/Creating_Interfaces. It wasn't easy. But... In trying to address your points, I fear it sounds like I think D-Bus is bad. That's not what I'm trying to say. I'm saying D-Bus/QtDBus didn't work *for my use-case*. So I created something that worked better *for my use-case*. There are cases where shared memory is better than sockets for IPC. There is a single perfect solution. I have a HUGE simplifying assumption that all processes use Qt. That cuts down where Replicant is useful quite a bit. But with this assumption, I can make IPC pretty easy. And that was valuable to me, especially in the churn of early development. Thanks, Brett _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
