What we really want to know Charley is whether you drive a F-150 or a Prius. That will decide whether this is a Killer App.
md On 6/1/2014 9:43 PM, charleyb123 . wrote: > 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
