Messages in this thread | | | Subject | Re: All this resource-fork AKA multiple stream nonsense | From | Andreas Degert <> | Date | 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/
| |