Path: utzoo!attcan!uunet!clyde.concordia.ca!mcgill-vision!snorkelwacker!bu.edu!orc!decwrl!elroy.jpl.nasa.gov!ames!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent
From: brent@terra.Eng.Sun.COM (Brent Callaghan)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS protocol
Message-ID: <136362@sun.Eng.Sun.COM>
Date: 30 May 90 00:32:20 GMT
References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <2284@sequent.cs.qmw.ac.uk>
Sender: news@sun.Eng.Sun.COM
Lines: 56

In article <2284@sequent.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts) writes:
> The NeFS spec is quite clearly written as a slight
> generalisation over supporting a couple of slightly non-UNIX
> file systems. It doesn't go anywhere near supporting
> significantly different systems such as the Macintosh ("You
> mean each file has two parts, plus comments?") even though the
> polymorphic nature of PostScript would make it easy to allow
> things like arrays or dictionaries of filehandles rather than
> just single ones to be returned from open (for example).

The NeFS protocol goes a long way toward making Mac implementations
more efficient.  File attributes are represented as a dictionary -
name/value pairs.  The resource and finder forks of a Mac file
could be represented as attributes of the data fork.  Alternatively,
if the server is not a Mac server and is not capable of supporting
arbitrary attributes - we can fall back on Applesingle or
AppleDouble representations.  Either way, the protocol allows
a Mac client to construct a single NeFS request to do what it 
wants.  Consider the NFS requests required of a Mac client:
to open a folder on the Mac desktop requires
a READDIR to enumerate the files, then a LOOKUP on *each* name
to obtain its attributes, followed by a READ on some of the
files to get the icon.  

> Flexibility is good, but NeFS seems to me to be all wrong. It
> dismisses the low-level network stuff with some hand waving,

The draft spec for NeFS is deliberately vague about "low-level
network stuff".  There's nothing to be gained by spelling out
in detail what transport is going to convey requests between
client and server at this stage in the design.  Currently, the
prototype is built on RPC/XDR like NFS because that's what we
know best. Eventually there will be a document that defines
the protocol as expressed by RPC/XDR.

> and it just feels like an insane way to go about something
> which needs to provide very high performance.

Why insane ? If we're talking client or server CPU there
isn't really a lot of difference between NFS and NeFS.
The client just transmits "canned" requests - these do
not have to be generated on the fly.  Existing NFS servers
already employ an "interpreter" of sorts: the server
currently executes one "operation" per request as defined
by the NFS procedure number.  The NeFS protocol just allows
the client to string a bunch of operations together.
The overhead in executing these operations is extremely
small; it's just tiny drops of glue between vastly more
expensive I/O operations.  Remember: the drops of glue
have the potential to eliminate hugely expensive
over-the-wire operations.
--

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 1051