On Sat, 27 May 2000, Greg A. Woods wrote:

# No, that's not the point.  However given that I've more or less rejected
# by now the very notion of RPC in the first place I'm not likely to be
# swayed by a new implementation of it, no matter how much easier it is to
# use than Sun's "popular" incarnation of RPC.

After watching the ping-pong match between the two of you, may I
hazard a guess that you also consider NFS to be overblown for what it
does?  After all, NFS uses RPC.

It strikes me that NFS is actually a much lighter-weight protocol than
any of the other proposed/implemented remote file access protocols,
in spite of its perceived evils.  It also admittedly doesn't try to
do as much (compared to, say, RFS, which, last I looked, tries to
open remote devices remotely instead of locally -- occasionally very
handy)...

But if there's a protocol for remote file access which is:
	- reliable
	- robust
	- fast
	- light-weight
	- free

I would very much like to know of it.

# system).  The basic idea of a remote procedure call may be such an
# abstraction, but as yet I've not seen any implementation even remotely
# light-weight or simple enough to meet my stated requirements.  Solaris
# doors certainly doesn't seem to fit any better than the original Sun RPC
# does.

I'm skeptical to see yet another file type which is something that would
probably be as well served by a domain socket or a named pipe.  After
all, we're doing not much more than machine:process to machine:process
tunneling.

I recall at one point that portals used to exist (portals were kind
of like pipe/sockets with ACLs attached to them, IIRC).  Those were short-
lived because nobody was able to properly implement them.

				--*greywolf;
--
BSD: Scalability Does Matter.