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    [W:0.027 / U:152.488 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site