Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!intercon!news
From: amanda@mermaid.intercon.com (Amanda Walker)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS protocol
Message-ID: <265DFAD2.5818@intercon.com>
Date: 26 May 90 03:41:06 GMT
References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <1990May24.205149.6065@Neon.Stanford.EDU> <3385@auspex.auspex.com> <1990May25.234950.1465@Neon.Stanford.EDU>
Sender: usenet@intercon.com (USENET The Magnificent)
Reply-To: amanda@mermaid.intercon.com (Amanda Walker)
Organization: InterCon Systems Corporation, Herndon, VA
Lines: 27

In article <1990May25.234950.1465@Neon.Stanford.EDU>, pallas@Neon.Stanford.EDU
(Joe Pallas) writes:
> Now you may call those invocations programs, but they're really just RPCs.

Yes and no.  They are RPCs in the sense that any client/server transaction
is an RPC, but the important difference between NeWS & NeFS and, say, X &
NFS is that the RPC is defined by the client, on the fly, to suit the
client's needs, not defined in advance by someone who has to try and figure
out what clients will want.

Let me take a presently hypothetical example: a file service client for
my favorite machine, the Apple Macintosh.  The biggest problem with doing
this under NFS is that, despite a reasonable correspondence between the file
systems themselves, the *operations* performable on a file system vary quite
a bit between the Mac OS and NFS, thus requiring a ridiculous amount of either
network traffic or client-side caching in order to get acceptable performance.
With NeFS, the client can blort over some code that tells the server how
to implement those operations that the client is going to want to invoke.

Flexibility wins.  This is probably even more true for file service than
for display service...

$.02,--
Amanda Walker, InterCon Systems Corporation
--
"Go not to the elves for counsel, for they will say both no and yes."
	--J.R.R. Tolkien, The Lord of the Rings