[Development] Request for a sandbox area: Replicant

[charleyb123 .]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140601/f1b11fed/attachment.html>