Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!bionet!agate!shelby!neon!pallas
From: pallas@Neon.Stanford.EDU (Joe Pallas)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS protocol
Message-ID: <1990May26.213221.15248@Neon.Stanford.EDU>
Date: 26 May 90 21:32:21 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> <265DFAD2.5818@intercon.com>
Organization: Computer Science Department, Stanford University
Lines: 20

In article <265DFAD2.5818@intercon.com> amanda@mermaid.intercon.com
(Amanda Walker) writes:

>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.

We have no disagreement here.  My point is that, for Amanda's
presently-hypothetical Macintosh NeFS client, the code which gets
dynamically loaded into the server to define the Mac-appropriate RPC
interface (things like lookup_file_ignoring_case, e.g.) will be
written by humans, not programs.  NeFS clients don't write code, they
invoke code written by NeFS client implementors.

And filesystem code will be even more complicated than graphics code,
which is hard enough for humans to read and write in PostScript.

joe