Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

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/