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

    > 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 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

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.026 / U:17.388 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site