(I'm just jumping in here...) <snip, Replicant for IPC>
Bret spaketh: > 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 > 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: http://linuxgizmos.com/tiniest-linux-com-yet/ ) Brett mentions: (1) Assume processes are not on the same hardware (e.g., can't do shared memory) (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 simpler-is-better. 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>... --charley
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
