Re: Our introduction to Reiser-list

[Jonathan Briggs <jbriggs@esoft.com>]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

On Thu, 2005-10-27 at 12:20 -0700, Peter van Hardenberg wrote:
> On October 27, 2005 04:17 am, David Masover wrote:
> > Peter van Hardenberg wrote:
> > > On October 26, 2005 10:02 am, John Gilmore wrote:
> > >
> > > And I thought the whole idea was to unify the namespace and make things
> > > like ID3 tags obsolete...
> >
> > The two are not mutually exclusive.  You unify the namespace, and use
> > that to access things like ID3 tags.  Of course, eventually ID3 tags
> > become obsolete, and the information is instead stored outside of the
> > file itself, as a separate stream (treated as a file).  You'd have a
> > standard way of serializing any given file and all its metadata, so that
> > "something like id3" doesn't have to be re-invented for every file type
> > that has metadata, and so that similar metadata can be accessed through
> > a standard mechanism -- searching for a particular artist should return
> > songs (using id3 tags) and music videos (using the mpeg equivalent) and
> > maybe even song lyrics (using separate metadata).
> 
> It's much easier, more extensible, and more secure to create a utility which 
> ties together a number of userspace metadata libraries to create static files 
> than to move them all down into kernel space. I feel plugins providing 
> pseudofiles should only be used when there is no viable alternative.

And with transactions, it can be safe against becoming out of sync
(which is one of the arguments for doing it in-kernel).

Scenario:
        Reiser4 detects a file update about to happen.
        Transaction opens.  Changes are now invisible outside
        transaction.
                File contents are updated.  
                User space helper is called.
                Metadata files are updated.
                User space helper exits.
        Transaction closes.  File and metadata updates are now visible.
-- 
Jonathan Briggs <jbriggs@esoft.com>
eSoft, Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]