Messages in this thread | | | Date | Mon, 5 Jul 1999 17:44:54 +0200 | From | Jamie Lokier <> | Subject | Re: All this resource-fork AKA multiple stream nonsense |
| |
Joe Hohertz wrote: > 1) You can use regular file tools to manipulate directories. Is this really > important, or just a parlor trick to amuse one's friends? What is so > evil (or hard) about: > > (cd /srcdir && tar cplf - .) | (cd /destdir && tar xpvf -) > > or cp -a (for linux) or cp -Rf (for all other *nixs)
Apparently "GUI lusers" can't use archiving tools. Which is no big deal for copying, but a pain when they want to attach a "compound document" to an email using they're old favourite mailer.
I do think it's worth having compound documents _as files_ one way or another.
> 2) You can use it to break down complex files into a series of less complex, > but related files, for applications such as word processors, desktops, > spreadsheets, bla bla bla. This would be for the purposes of: > > - splitting text, image, other-data(tm) streams > - embedding icons into files, and other GUI related metadata > storage. > - keeping related metadata under one 'umbrella' > - the example cbbrowne@godel.brownes.org proposed about > keeping RCS information under one file with multiple > forks, I admit, looks cool.
You forgot one:
- I'd like to invoke "gimp my_document/picture_number_1" without having to "export" the image first and "import" it back after editing.
This sort of thing will work fine in a good compound document application framework -- and one of those is required anyway for cross-platform support. It would just be _nice_ to be able to dig into a document without having to use the framework.
-- Jamie
> 1) As had been stated by several people before, anything that comes out of > this in the form of a linux-specific kernel change will go the way of the > dinosaur for the following reasons: > [...]
You've shown why it must be implement in user space, that's all. It could have kernel support by way of _efficiency_ and _convenience_.
Since we like to keep things orthogonal here, if there are any kernel changes, best to keep them independent of compound document frameworks that we may have in mind.
> I actually rely on 'mv * /newdir' NOT moving directories.
It already moves directories :-)
> Why should the kernel and/or libc be responsible for being able to > deconstruct a file into it's base components? That's what an > application-level API is for! I don't really care that I won't be able to > use 'xv' to view the images in my word-processing files. If I want to > look at them, I'll fire up the word processor.
Good for you. I don't want to fire up the word processor -- it might take ages to load the 35 fonts etc. which I'm not actually interested in looking at.
Look at it this way: when you want to change the logo on your web pages, do you load up Netscape Composer first? No, you just get on and edit the image.
As for API: I'm for having the components as _separate_ files in directories. Let the "convenience" features of libc/kernel hacks make it appear as a file, but let the underlying thing be a directory. On other systems it will always look like a directory.
People seem quite happy with this for web pages.
> I guess the conclusion to this is, that applications should determine how > they store their data
This is the standardisation problem. A big part of this discussion is about "compound documents", which require a number of different applications to edit them. Web pages with inline images are probably the best example. Presentations with graphs built from tiny spreadsheets are another (the presentation document contains a diagram component which contains a spreadsheet).
> If the GNOME/KDE people want to write a library that provides a > globbed format (like a mini-virtual filesystem), and standardize on > that, then great.
I think this is a great idea also. It does have to be cross-platform first and foremost.
> They could > have tools to extract/stuff files into said files, and they could even > integrate support for looking at these files as directories (which I know > for a fact GNOME's filemanager does NOW for the case of tar files.) > > But when I use cp/mv/rm/tar/cat/less/whatever, that file should be > treated as just that, a file, nothing less, nothing more.
Hold on, what if the "standard format" is a directory full of files? As is so often the case for a web page?
-- Jamie
- 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/
| |