

  Just What We Need: Another RPC Package  - prakash
http://steve.vinoski.net/blog/2008/05/22/just-what-we-need-another-rpc-package/

======
ajross
After three decades of minimal-to-mixed success, you would _really_ think
people would have figured out by now that RPC is a fundamentally flawed
metaphor. It's not pipelineable, which means that it's always going to be
slow. It's a deadlock waiting to happen. And it's obscure: it takes the simple
notion of calling a method (say, to extract a single field) and hides from the
programmer the fact that this simple object might live on another side of a
content. Just a disaster.

Without exception, every successful network protocol has a query/response
structure. Even things that are "technically" based on an "RPC" protocol (NFS)
have evolved in this direction for performance and simplicity. Take a look at
the code for an NFS stack and see if you can see the "procedure calls" to the
remote server. They aren't there.

------
huhtenberg
Given Cisco's history of designing and standardizing protocols, I'll consider
their RPC protocol over SOAP at any time (even having a cursory knowledge of
it).

The problem with SOAP is not that it's bloated or that doesn't allow for
efficient parsing or whatever the flaw du jour is. _The_ problem is that it's
was created, promoted and embraced by people ignorant of established protocol
design practices.

If they wanted interoperability, there was an ASN.1 in DER or PER encoding
readily available. If they wanted forward compatibility - why not use trivial
TLV encoding ? And why the hell would anyone want to use text-based protocol
for passing binary data around ? "Easier to troubleshoot" they say. Huh ?! ARE
YOU NUTS ? Why not render the data into a .png then and exchange those instead
?

</rant>

So, I really hope Cisco does standardize their protocol. RPC may be a flawed
approach to begin with, but at the very least there'll be a decent protocol to
utilize this "flawed" technology.

------
aggieben
Topic story was not all that interesting (Cisco re-invents the wheel!), but it
led me to Thrift (<http://developers.facebook.com/thrift/>) and Ice
(<http://zeroc.com/index.html>), which I didn't know about.

------
ComputerGuru
I see a lot of RPC-bashing going on here... I actually use it (typically via
higher-level wrappers in Java or C#), and it's OK.... but what do you guys
recommend as an alternative?

~~~
ajross
Alternative for what problem? The issue is that RPC tends to fool people into
spamming the network. Where a traditional database query would issue one
request and get back a thousand rows of eight columns in a pipelined stream, a
(dumb, but entirely plausible) RPC architecture might end up iterating over a
thousand _remote_ objects, calling an accessor method for each field, and
making thousands of synchronous round trips to the server to accomplish what
the SQL query did in just one.

------
LogicHoleFlaw
CORBA, SOAP, JSON, REST... do we really need a new RPC stack? I don't see any
new value here. In the end you can't hide the network.

~~~
ajross
JSON isn't an RPC protocol, it's a data format. And REST is a web
architecture, it lives at a higher level (and on top of HTTP, which is not an
RPC protocol).

RPC architectures are things likes Sun-RPC, CORBA, SOAP, XML-RPC, DCOM/COM+,
etc... They model the network as a bunch of objects on which you can call
methods/functions from within an existing programming environment. Which
sounds like a nifty idea until you try it and discovers that it sucks (see
above rant).

~~~
LogicHoleFlaw
Pardon me, I'm just bitter today after wrangling with unruly WSDLs.

