For my part at least, I'd like to clairify the actual design goals =
before I get carried away with possible implementations. Assuming anyone =
wants my deisgn input anyway! ;)

There are two functional issues we're dealing with:
	1. Security -- we want ACL's
	2. File assocations -- we want be be able to exexute "file.gif" and see =
it, or maybe "cd " into file.tar as a 			directory.

To cliairfy. The goals are, something like:
	1. Exisiting userland code should not have to change at the =
source/binary level
	2. Enhanced userland utilites are viable. (an "ls" option to show new =
file details)
	3. Userland daemons are a viabale addition. (would the system break w/o =
them?)
	4. Kernel modifications should be limited.
	5. UFS compatability should not be compromised
	6. POSIX compilance should be maintained as far as standard fopen() =
etc.
	7. We're not straying from the standard UNIX way of doing things. (this =
ain't gonna be BSD5.0 ;))

The mechinisms related, include:
	1. the vnode driver
	2. the portal/union/null fs
	3. the exec() stuff
	4. NFS code

I'm trying to get a gauge on what exsisting technology exists to =
possibly be re-shaped/re-glued into something else. (we'd call this a =
"technology assement" in house, usally part of the first design meeting)

Competeing/Attractive exisiting relevant things include:

	1. Amiga's non-system (core/kernel) dependent approach
	2. HURD's translator mechinism (I think this is a biggie)
 	3. VMS structed files (yikes!)
	4. NT-like securuty. (as far as user ID)
	5. Other UNIX's C2/C3 level securty mechinisms
	6. VMS/NT regisrty files for both advanced file security and NDS (down =
the road)

Have I covered the bases for what's on the table? Or am I way off base? =
(pun, pun)

thanks for listening.

	-Paul