Jim Whitehead's Comments on my article comparing protocols and RPCs.
A couple thoughts:
* The protocols vs. RPC distinction isn't super strong. The RPC label is
good — I just don't like the "protocol" label. I think you could develop a
better name for this concept ("domain-tailored protocol (DTP)" perhaps?).
Many aspects of HTTP do fall within the general remote procedure call style
of interaction, and you yourself state that RPCs could do everything that
DTPs do (even though they don't). In my view, the distinguishing
characteristic is that DTPs have been tailor-made for a specific domain of
use, and by focusing on that domain, you can exploit patterns of use to
develop a more optimal clumping of functionality into protocol verbs.
* This paper makes it sound like protocols do not have well defined
abstractions scoping each protocol verb, when in fact they do. I view this
as a grain size issue — protocols verbs are "bigger" abstractions than RPC
verbs.
* You could easily add a section describing the relevance of this analysis
to the XML-RPC/SOAP movement.
* Come on, take two seconds and compute 1/2 the equatorial circumference of
the earth.
* You write:
Designing high performance protocols is hard and most likely beyond the
ability of most programmers. It is an issue that will have to be left to the
experts for the foreseeable future.
Yet in your RPC vs. HTTP example, you use SMB as your "RPC" example. Yet,
SMB (and its cousin, NFS) were both designed by experts and were optimized
for their specific domain. This implies to me that there is more going on
here than simply quickly-crafted RPCs vs custom designed protocols. Yes, NFS
and SMB have poor performance over the Internet, but the cause isn't that
they were quickly thrown together.
* I get the sense that Roy Fielding's work on REST (see attached paper)
might be relevant to this issue.
* Caching (ability to handle it) might be another way of differentiating RPC
vs DTPs.
– Jim