Re: All this resource-fork AKA multiple stream nonsense

Andreas Degert (ad@papyrus.hamburg.com)
06 Jul 1999 18:12:08 +0200


Jamie Lokier <lkd@tantalophile.demon.co.uk> writes:

> Hold on, what if the "standard format" is a directory full of files? As
> is so often the case for a web page?

I donīt think this can be solved by fighting over if the proper
representation (or even the default representation) should be a file
or a directory. It depends; some applications always want to see a
file, some always a directory, and some need both.

Maybe a better concept would be to define different "views". So far,
i've seen at least 3 possible views:

1. a directory
2. a file ("default file", for example an executable)
3. a flat file containing everything

If I want to start gimp on a picture in a compound document, i need
the directory view. If I want to send the document over the net (ftp
or mail attachment), i need a flat file. When the shell searches for
an executable, it would be nice if it could look like an ordinary
executable in this case (and maybe we'd call it "albod" instead of
"compound document").

For applications that don't care (or old applications) there should be
a way to specify which view they will get (environment? something in
elf header?).

Applications that are written to take advantage of multiple views need
a new API to access those views.

I'm not sure how this can be done. It would be nice to have one
solution entirely in userspace (makes it portable), and to think about
where kernel (vfs or filesystem) support could make it more efficient,
safer, or bulletproof. If we don't want the kernel to process the
content of files it doesn't seem to be a good idea to implement it
entirely in kernel space.

Perhaps a good time to take a look at gnome libefs (i'll do that now ;-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/