lkml.org 
[lkml]   [2005]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: reiser4 plugins
    Zan Lynx wrote:
    > On Thu, 2005-06-30 at 14:47 -0400, Horst von Brand wrote:
    > [snip]
    [snip-some-more]
    > Structured files are fine when they're small but quickly become
    > disgusting as they get bigger. Either you slowly rewrite the whole
    > thing or you "fast save" by writing new sections to the end of it that
    > replace existing sections. That's how you end up with documents that
    > contain "deleted" information that was supposed to be confidential.

    Doesn't OpenOffice already do something similar with zipfiles? I
    remember noticing huge differences in save times after adding large
    images to a presentation versus just changing some text. So, it's
    obviously not repacking each image every time I save. But, as the
    internal text is all XML, I doubt it's leaving "deleted" sections lying
    around.

    > Having the filesystem track each part for you and then creating a
    > structured file when needed (and without needing to remember to run a
    > special tool) is a far better idea. (reiser4 doesn't do this but its a
    > possible idea)

    Been discussed to death, and chances are, Reiser4 will do this with
    plugins. I imagine it being implemented in a more general way, though.
    For example, a meta-file which, when read, produces a
    zipfile/tarball/dump of the directory it belongs to. Then, to send such
    a document via email, you just navigate to the directory where it lives
    while looking for files to attach, only from /meta/vfs as a base, then
    attach the meta-file. The zipfile gets built automatically.

    To simplify the process, all you *really* need is a button on all FS
    navigation windows (Nautilus, Open/Save dialogs, etc) to switch back and
    forth between the meta view and the normal view. That, or a separate pane.

    This way, instead of patching the mail client to support all possible
    transformations you'd want to do before sending, or patching all
    applications to use zip (and any other transformation a user might want
    to do), or forcing the user to run another app, you automatically get
    *all* available transformations, in a way that could potentially look as
    smooth as adding zip support directly to the app.

    > Another advantage to file-as-directory is being able to access all the
    > file's meta-data through a single channel: file names and text data.
    > It removes the need for chmod, chown, touch, getxattr, chacl and all the
    > rest of the special tools needed to work with Unix files. It also makes
    > it far easier to add new meta-data in the future, because no new tools
    > have to be written to use it.

    All good points except the last one. New tools vs new plugins? People
    already know how to write the tools...

    > So that's two reasons to bother.

    That, and the possible paradigm shift. Navigating to the /meta dir for
    a file could be the commandline equivalent of right-clicking on the file.

    Of course, to some people, paradigm shifts are a reason *not* to bother...
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-07-01 09:22    [W:4.061 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site