> > This cross process stuff is starting to feel like 1996 and > remote procedure RPC calls, now using QT signals and slots. "<drool>" > again for effect. > > One could review the history of microsoft and the fine RPC mechanisms > that turned out to be mostly unusable, or maybe just unused. > > Keep the optimism in check folks. We have a lot of devices now in the > mix, not just Win32. >
I understand your assertion. By 1996 I'd already completed multiple CORBA projects for the telecom and aviation industries. You're right -- it was largely unusable. Hence, those technologies are pretty much gone now (too expensive and problematic). That era had problems: (1) Too complicated (security, platforms, versioning, etc.) (2) Really big foot print. (3) Really expensive tooling (pricing, and hardware requirements) (4) Profound invasiveness/coupling across the tiers (5) Non-scalable (real-world designs could not evolve without profound cost or rewrite, despite promises to the contrary) (6) Inability of the "standard" to be implemented (it was massive) (7) Inability of the tools/libraries/APIs/standards to evolve (the "standard" and "industry variants" were too big/complicated) So, everybody shifted to "lighter" stuff, like RPC/SOAP/RMI/REST. However, these don't solve the fundamental issue: Asynchronous type-safe messaging across processes. Fundamentally, you can't have it. (Not today, with current approaches; you have to roll-your-own.) I agree that today's "lighter fare" (like HTTP/REST) is better than "back-then". However, that means you have to serialize to XML or JSON, and do your own marshalling to/from your higher-order types. Yes, it's simple. But, it's tedious. The first thing any "sane" person would do is wrap (hide) that detail so the system doesn't "see" it. That's why I want the library. Today's assertion is more specific: Cross-process and cross-hardware scaling requires: (a) Asynchronous/non-contention (i.e., "messaging" designs) (b) Type-safe APIs (beyond POD, handling data marshalling) The signals/slots approach is a new variation over the past, and over what's widely used today. IMHO it is an elegant approach (Qt users already design for (a) & (b) when we do signal/slot). Don't make me define a schema. If I pass a QVariant to another process, it had better show up as a QVariant. If you make me define an XML/JSON schema, I'll do it as an implementation detail, but I won't tell anyone about it (because I "own" both ends). If I want to give a customer access to one end, I'll give them a library that lets them work with "real-types" and which handles internal control flow/timing details, and not an out-of-date JSON schema description. That's why this should be a library. A "generalized" solution is possible here. That's why I'm saying "killer app". Yes, the "downside" is that I need Qt on "both ends" -- so a QVariant is "sent" and then "received" (through signal/slot). However, this is *also* why it offers benefits that today's other technologies cannot match (transparent serialization and notification). But, since we already use Qt as our cross-platform porting layer, IMHO this is a "feature". True, large distributed systems may need other things like "network topology" management (nodes come-and-go, security, etc.), but IMHO that's pretty secondary and not terribly difficult to scale on top of the "premise/approach", which is type-safe cross-process messaging. The reason why RPC died and HTTP/REST dominates is the simple fact that > HTTP/REST is SIMPLE. Not 10 million bloody incomprehensible parameters > like RPC. > Whey does SOAP continue to decline? Extra complexity for little or no > gain. Who wants to worry about WSDL? With HTTP/REST, If you do not have network connectivity, the ergonomics > are dictated by a simple timeout and an HTTP/404 error or something like > that. > WIth RPC, you could NEVER tell why it was not working. But you were > SURE it was NOT working. Sometimes, you were not sure it WAS working. > Let alone a human being operator getting meaningful feedback > and the library supporting such simple feedback. > What does error WM_ERRORBASE+IPCERRORBASE+CUSTOMIPCERROR mean? > These are fair points. I separate the two: (1) Ease-to-use: Signals/slots across processes is "hands-down" superior in every way than anything listed above. (Simpler, more correct, more elegant, easier to scale.) -- If it works. (2) Ease-to-setup/administer: I don't know yet. This will be an important detail. I think this is consistent with your concern above, which is one of the reasons HTTP/REST is so popular now (it's easy to setup and diagnose). So, I concede you raise good points. However, if it is easy to setup-and-administer (if we can properly address [2]), then I continue to stand by the "Killer App" assertion. --charley
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
