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/