| From: | Jim Peters |
| Date: | 13 Sep 2000 at 16:06:23 |
| Subject: | Re: AMIOPEN: ACR #1: Intelligent FileSystem |
On Tue, Sep 12, 2000 at 03:18:45PM +0200, Aaron Optimizer Digulla wrote:
> - Depending on the type of the "file", it should "contain" some
> default files. Examples a file demo.txt would contain a text file
> demo.txt/type which contains "ASCII Text" or similar. demo.gif
> would contain demo.gif/type "GIF Image", .../width, .../height
> and maybe .../thumbnail. If .../thumbnail exists, then it will
> be a picture (any supported type). thumbnail will probably also
> contain elements (but no thumbnail :-)
Two ways I can see you going with this - either attach an extra .info
file (or info fork, or whatever) to each file, or have a Mac-like
file-type identifier, which is similar to a file-name extension, only
hidden.
If you use the extension/file-type identifier idea, then the space
overhead per file is very small, and everything with the same type is
handled in a centralised uniform way (no old imported files
referencing tools you don't have any more). A tool that knows how to
handle GIF images, say, would register itself, and would then be
called on to handle the sub-file-system that appears under
image.gif/*. It would only be able to give you information that could
actually be found within the GIF file. This wouldn't do everything
that you'd like regarding attaching arbitrary comments and tags and so
on to a file. Still, the GIF-handler tool could fill in a lot of this
- like a default viewer or whatever - from a list of OS-registered
image-viewers.
The big thing for me is that I wouldn't want the overhead of a .info
file/fork for *every* file on the system. I'm thinking of my mail
directories, full of hundreds of tiny files.
The other thing is - don't you think with this idea you would start to
lose a hold of reality ? Is this thing I'm editing a real file or
part of a ZIP archive, or a generated sub-component of a file - does
this thing really exist ? At least as it is now, a file is a file,
consuming disk blocks in a directory. Lots of tools (apart from the
user) will have to know whether something is `real' or not, otherwise
your backup script will be backing up a ZIP archive, and then each of
the files within it, or your GIF file, and then a generated thumbnail,
several scaled versions and the original in 24-bit colour.
Maybe some kind of indication that we are entering an `alternate
reality' is necessary, like a colour change in the background to the
shell or desktop window, or some other psychadelic enhanced-perception
altered-state type effect.
Anyone looked at the Hurd approach, which is somehow similar, from
what I've heard. You set up `translators' that produce a temporary or
permanent virtual directory out of nowhere. This could be from a ZIP
file, or from a remote machine, or from an FTP link, or anything,
depending on the translator. Check out this link (although the GNU
site was down when I looked just a moment ago), or do a search:
http://www.gnu.org/software/hurd/hurd.html
Jim