[Development] Request for a sandbox area: Replicant

[Stottlemyer, Brett (B.S.)]

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