lkml.org 
[lkml]   [1999]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2011 Jasper Spaans