[Development] Request for a sandbox area: Replicant
charleyb123 at gmail.com
Sat May 31 14:49:29 CEST 2014
(I'm just jumping in here...)
<snip, Replicant for IPC>
> 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
> 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
> I can make IPC pretty easy. And that was valuable to me, especially in
> the churn of
> early development.
I am *HUGELY* interested in this. We do lots of IPC, and across physical
devices, and his design issues really "hit home" for us. Part of the
reason for our interest is we've implemented similar things, and the
"design-approach-overlap" is uncanny. (That's a CAN bus joke.)
We'd really prefer to not "grow our own", because all of this is mere
"plumbing". We want signals/slots across processes, and across devices
(physical hardware). The "Prime/Replicant" model concept really does work
nicely for this (I haven't looked at Brett's code, I'm just nodding a lot
as I hear him talk about it).
Did you guys catch the "VoCore" a few days ago (small Linux stack module)?
This kind of thing is going to be *everywhere* with the new
"internet-of-things". After attending QtDevDays for the last couple years,
it's already clear that (today) you can "ssh" into your vacuum cleaner,
stove, and refrigerator. IMHO, transparent signals/slots across hardware
stacks will be a "killer app" for Qt (in addition to its cross-platform and
declarative interface). (VoCore:
(1) Assume processes are not on the same hardware (e.g., can't do shared
(2) Assume processes have different target OS (e.g., Linux, Windows)
(3) Assume processes have Qt
We *also* are willing to make these, "HUGE simplifying assumption[s]" to
make IPC pretty easy. Effectively, if all IPC were expressed as mere
"signals/slots" across processes, that would be *awesome*. Unbelievably
Awesome. Killer App Awesome.
I estimate this would effectively cover 80+% (maybe 90+%) of the IPC
use-cases, with the remainder being dedicated sockets for
volume-data-transfer. We do both, but I'd guess *most* applications are
nearly 100% status-and-control across processes. (That's the whole point
of RESTful interfaces, and why it is increasingly popular.)
Recall that today, signals/slots are "thread-safe bridges" to enable
messaging across loosely coupled objects. That's exactly what we're
talking about here, but also across-processes (and across hardware).
Making it work across processes is already "design-consistent" with today.
IMHO, that's a Killer Application.
This is also the *whole point* of a microkernel such as QNX that merely
enables messaging-across-processes. Simple. Reliable. Bullet-proof.
Scales nicely. No locks/contention.
One design implication is the new need for some type of code generation
(e.g., extending "moc"), which Brett mentions he did. We did this too.
It's necessary to manage the adapter code that no human should write,
based on some kind of protocol or interface specification for the
"Prime/Replicant" bridge. Things like "IDLs" were used in the past, and
"CORBA-like" systems added functionality like enabling versioning,
security, and lots of complicated things "on top", but IMHO
This is "plumbing". It should be in a library. Sitting on top of Qt.
Providing simple type-safe cross-process messaging.
Signals/slots transparent across processes... <drool>...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development