Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!decwrl!sun!guy
From: guy@sun.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Seeking a Development Environment (Sun?)
Message-ID: <8423@sun.uucp>
Date: Thu, 23-Oct-86 04:18:07 EDT
Article-I.D.: sun.8423
Posted: Thu Oct 23 04:18:07 1986
Date-Received: Fri, 24-Oct-86 00:21:52 EDT
References: <4254@brl-smoke.ARPA> <935@kbsvax.steinmetz.UUCP> <30ceeabf.809c@apollo.uucp>
Organization: Sun Microsystems, Inc.
Lines: 47

> The framework is, I would claim, a better (dare I say "more open") thing
> to have than simply NFS.  One could build NFS support using the framework.
> One could build ISO/FTAM support with the framework.  One could build
> something that FTP'd a whole file over to your machine on open and back
> on close, if that's the best you could squeeze out of an uncooperative
> remote system.  Better that then nothing.
> 
> As far as server-side support goes, writing servers (especially stateless
> ones) that do the things that remote clients ask it to do just isn't
> that hard.

I think you'd better say "half-open".  It certainly makes life nice for
clients running on Apollos.  However, even if you publish a protocol
specification, it doesn't do anything more for *non*-Apollo clients than NFS
does; they either have to 1) rewrite their applications to use special calls
to access remote files, 2) build wrappers around their OSes file I/O calls
that use this protocol when accessing remote files, and relink all programs
that can be expected to want to access remote files with a library
containing these wrappers, or 3) stuff the remote file access code into
their kernel or some other dynamically-bound library so that existing
programs automatically get the new version of the code.

In short, what you have is a nice feature *for Apollo's OS*, not something
that magically opens up everybody's system.

I freely admit NFS doesn't do that either; you have to do some amount of
work to fit it into an arbitrary OS.  However, if you fit it into a UNIX
system using the vnode interface that comes with NFS distributions, you have
a framework that you can use to build support for other kinds of file
systems - whether remote or not - into your system.  (For example, we have
an MS-DOS file system that plugs into the interface, which you can use to
read and write MS-DOS floppies on UNIX systems.)  Yes, you have to stuff
some amount of kernel code into your system to do that, but that's due to
limitations of code based on the standard Bell Labs implementation of UNIX;
remember, the basic structure of UNIX was developed in the late '60s and
early-to-mid '70s on a PDP-11, so there was a limit on how much effort its
designers put into worrying about things like object-oriented file systems.

Comparing "extensible streams" (Apollo's object-oriented file system) with
NFS is comparing apples and oranges (or maybe knives and schoolbuses?);
better you should compare "extensible streams" with the vnode interface or
the File System Switch, or your remote file implementation with NFS, RFS,
etc..
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)