Well, if the application has generated the single document as many files,
whose fault is that? The application designers
> I do think it's worth having compound documents _as files_ one way or
> another.
Sure, but stored as a single stream, using a virtual filesystem or stream
multiplexing library.
> > 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.
Isn't this also something that could best be done in the gui framework ala
OLE? I think gnome is working on this now (i think it's called gnorba?)
and KDE has had their equivilant for a while too.
In this case, gimp *might* be able to invoked in this way, assuming it has
been compiled with support for such things. (Implemented in a userspace
library.)
Sure it might be nice to dig through it, but breaking everything else is
considerably less nice.
You want kernel support? How's this scenario:
- a VFS or streams based implementation is created as a C library
- gnome/kde/whatever uses this to create compound documents
- install userfs
- create a userfs 'module' (it's not a kernel module) against the C
library to let you browse it like a normal file
Or like I said before, midnight commander already lets you do this for tar
files, you could likely easily support this 'compound document' format.
> 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_.
Sure, I'm all for efficiency and convenience. But not at the cost of
breaking things.
Has anyone even for a moment considered the impact that kernel support
would have on things like POSIX compliance et al?
> 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.
So you agree that compound documents and kernel changes should be kept
seperate?
> > I actually rely on 'mv * /newdir' NOT moving directories.
>
> It already moves directories :-)
I noticed RH6 does. Bad example.... 'cp * /newdir' is more illustrative of
this.
>
> > 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.
So you can use whatever extraction tools come with the libraries I
proposed to do just that.
Also, how useful is it really to be able to do this? Isn't the image in
the word processor document a part of THAT document, and not really a
seperate entity for that purpose? To rephrase, wouldn't you really want to
edit the document component in the context of the WHOLE document? Makes
more sense to me.
> 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.
No. But I'm not the one (and I'm not sure anyone was) proposing we go
stuffing the HTML and graphics making up the whole page into a single
filesystem entity. Heck, while we're at it, let's put our CGI's in there
too. Maybe we can put the whole dang site in a single file with 3000
resource forks? Can you see how this scenario borders on the rediculous?
> 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.
Why bother with the single file representation at all then? It doesn't
bother most to tar up a website to transport it.
> People seem quite happy with this for web pages.
But they're not dealing with single documents. One directory of web isn't
necessarily one document, it could be many, or even a whole site, And
representing it as anything but a directory of files is futile.
> > 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).
Well my response to this is simple. If you want that kind of integration,
you're going to need a fair bit more than the ability to group files to
make it happen. Implementing what amounts to 'tar in the kernel' isn't
going to help with the formatting and embedding issues.
> > 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.
Which is a goal a C library can faithfully accomplish, and a kernel hack
cannot.
>
> > 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?
Nothing is stopping them from doing that either.
Joe
-
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/