Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!hp4nl!eutrc3!eutrc4!rcpieter
From: rcpieter@eutrc4.urc.tue.nl (Pieter Schoenmakers)
Newsgroups: comp.os.misc
Subject: Re: Front End
Message-ID: <769@eutrc3.urc.tue.nl>
Date: 29 Jun 89 19:29:37 GMT
References: <53645@aerospace.AERO.ORG>
Sender: news@eutrc3.urc.tue.nl
Reply-To: rcpieter@eutrc4.UUCP (Pieter Schoenmakers)
Organization: Eindhoven University of Technology, The Netherlands
Lines: 53

In article <53645@aerospace.AERO.ORG> abbott@aero.UUCP,
Russell J. Abbott writes:

>The directory/folder graph will actually include all directories/folders
>in the system, and perhaps on the available(?) network.  One can examine
>the entire file system (permissions permitting) by traversing the graph.

Is this workable? I can imagine a computer hooked onto a network with lots
of fileservers. I can't imagine the graph to be useful then,
   - taking extremely much display space or
   - needing a window with a very large extent, taking ages to traverse.
   - taking ages to build (all directories must be known).
   - needing lots of management (newly created directories must be reflected
     in the graph).

>Some of the leaves may be "intensional directories."  An intensional
>directory is a directory whose contents are specified by an expression
>rather than by a set of pointers.  (A Unix path expression e.g.,
>~/abc/de*fg, is a simple example of a expression that may be used to
>define intensional directories.)  The range of possible expressions is
>yet to be defined.  Most likely it will never be fully defined since
>there is no reason to prevent users from writing their own interpreters
>for directory expressions.
>
>One intended use of intensional directories is to allow a more flexible
>structuring mechanism for one's files.  For example, when doing software
>development one may want a single directory to contain source code,
>object code, and documentation for a module.  Yet, one may also want a
>single directory or directory structure that contains all the
>documentation for an entire system.  Intensional directories facilitate
>this by letting one build multiple structures over a base structure --
>more or less as one does with "views" in database systems.

You should design these expressions carefully, since regular expressions
just won't do, and you probably don't want users just to define a list of
files that must be held in the directory.
   How do you solve the problem of saving a file in an intensional directory,
while the files does not match the intensional directory's 'selecting'
expression?

How about using UNIX' links?

And what if a user deletes a file in an intentional directory, and sees
it vanishing in the 'real' directory? Not very consistent (though the same
problem occurs when using the UNIX links).

On the ADFS, a filing system used by the Acorn Archimedes, files don't have
extensions, and the '.' is directory seperator. This implies a C source file
to be called c.foo, which is the file 'foo' in the directory 'c'. Similar for
other directories like h, s and o. This scheme ensures a very neat directory
structure of a s/w project, your intention with intensional directories.

---Tiggr