Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!agate!darkstar!saturn.ucsc.edu!golding
From: golding@saturn.ucsc.edu (Richard A. Golding)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <11469@darkstar.ucsc.edu>
Date: 24 Jan 91 00:10:29 GMT
References: <5427@auspex.auspex.com> <42488@nigel.ee.udel.edu> <5461@auspex.auspex.com>
Sender: usenet@darkstar.ucsc.edu
Organization: University of California, Santa Cruz
Lines: 46

In article <5461@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>The menus specific to the application are in the application's code.
>
>That could be done with a separate file - or with *multiple* separate
>files, one per language, each containing menu information for that
>language, which seems a bigger win on a multi-user system *OR* on a
>single-user system getting the application from a file server.  You
>don't need to have the notion of a "resource fork" for this....

It's worth noting that this is exactly the approach taken for
applications using the X11 window system.  Each application has an
applications-default file, essentially providing the functions of a Mac
resource fork in the application.  Users can have additional resource
files, either loaded into the window server or separate.  The resource
files provide a hierarchical key space, and some X toolkits make use of
this for things like menus, text strings, and so forth.  The only thing
this lacks is document-specific resources, which could still be
provided (as a separate file) but which no applications (to my
knowledge) use.

This approach has a couple important benefits.  First, resource files
don't require any special mechanism, and don't affect any existing Unix
utility unless it needs to be aware of resources.  For example, `ls'
and `cp' work just the same as they ever have.  Making these
applications aware of resources is non-trivial, as witnessed by the
experience of the OS/2 designers.  Second, the technique is portable,
and doesn't depend either on the version of Unix nor indeed on Unix
itself; it works just as well under VMS.

In general, this whole argument seems silly.  Nobody in their right
mind is going to provide *any* kind of file system in the kernel, if
current trends are to be believed.  Any operating system worth
consideration would be able to use a new "filesystem" module (object,
server, ...) which provided complex semantics.  And Unix functionality
does seem to be the basis people are using to develop new systems.
Just where Plan 9 fits into this I wouldn't care to guess; I only have
read the UKUUG papers and they left me convinced that the system was
interesting, but that it was a research vehicle, and I would need more
information to make an evaluation (were I to want to).

-richard
--
Richard A. Golding 				golding@cello.hpl.hp.com or
  UC Santa Cruz CIS Board (grad student) 	golding@cis.ucsc.edu (best) or
						golding@slice.ooc.uva.nl 
Post: Baskin Centre for CE & IS, Appl. Sci. Bldg., UC, Santa Cruz CA 95064