Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ptsfa!hoptoad!academ!uhnix1!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.unix.wizards
Subject: Re: symlinks, and potential variants thereof
Message-ID: <271@nuchat.UUCP>
Date: Wed, 29-Jul-87 23:49:50 EDT
Article-I.D.: nuchat.271
Posted: Wed Jul 29 23:49:50 1987
Date-Received: Sun, 2-Aug-87 10:52:29 EDT
References: <2629@ulysses.homer.nj.att.com> <390@murphy.UUCP> <898@rtech.UUCP> <845@mcgill-vision.UUCP>
Organization: Public Access - Houston, Tx
Lines: 24
Summary: maybe generic-symlinks could be _active_ objects

In article <845@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes:
> [...] directory does, but when a lookup is done, if the name being looked for
> is not in the generic-symlink directory, the kernel follows the symlink
> and looks there.
> 
> This is a pipe dream at the moment.  In particular, I see problems with
> opening a file for write (assuming it doesn't exist in the
> generic-symlink directory).  Should it follow the link or not?  In the
> usage I mentioned above, it depends: for a source file, it should
> follow the link; for a .o file, it should create it locally.
> [...] for later use.  Perhaps lots of things.  Any ideas?

Well, the thought that leapt into my mind on reading this was
"why not use a program as the generic-symlink object".  It would
act as a filter for nami; this gets into the lightweight process
thread and probably a few others.

But this is exactly the idea I'm working on in my research, ie an
"object oriented" operating system, and as has been pointed out already
it would be stretching things to call such a system "UNIX".

	But we are all entitled to our pipe dreams, aren't we?
	Steve Nuchia    334 1204   (hire me)
	{housun,{soma,academ}!uhnix1}!nuchat!steve