[Development] Request for a sandbox area: Replicant

[md at rpzdesign.com]

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
>