Re: reiser4 plugins

David Masover
2005-07-01T07:18:06Z

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