🚀 go-pugleaf

--

In article <2493@sdcsvax.UCSD.EDU> wegrzyn@cdx39.UUCP (Chuck Wegrzyn)
argues for use of machine-specific RPC data formats rather than a
global standard format.  This method of course loses badly when the
number of different machine types grows large (since the number of
format conversion routines which must be implemented grows with n^2
instead of 2*n).  It also requires that all RPC implementations be
coordinated, since adding a new machine type to the network requires
that ALL machine implementations be changed when a new allowed machine
type is added.  As a practical matter, though, he might be right IF the
expected number of different machine types on a network is small and if
there is a central registry of the allowed machine types.  My
question:  are these two assumptions in fact realistic?

For a proprietary network, they are certainly realistic.  A given
vendor typically supports only a very few machine architectures.  For a
network standard they are of course unrealistic (e.g. the Internet
community would never want a standard that so limited the set of
allowed machine types).  How about for a typical research LAN?

Incidentally, instead of thinking of his type codes as describing the
client's architecture, one might better think of them as describing
which of a small registered set of standard RPC formats this client
is currently using.  So one might have 2 RPC encoding standards that
just happened to correspond to VAX and 68020 data formats; when adding
an 80386 to the network, the 386 implementor might choose to do 68020
encoding rather than register his encoding type also.

The real problem with RPC encoding schemes, by the way, is not machine
specificity but language specificity.  The preferred data encodings
for applications written in C are far different from those for data
when applications are written in Mesa, as a comparison of Courier with 
SUN RPC will surely demonstrate.  See Eric Cooper's thesis for more 
details.

--