Re: silent semantic changes with reiser4

[Wichert Akkerman <wichert@wiggy.net>]

Previously Spam wrote:
>   Because  having user space tools and code will make it not work with
>   everything. Keeping stuff in the kernel should make the new features
>   transparent to the applications.

But having it in the kernel has the same problem. If you read the
Solaris documentation you will see that a bunch of utilties had to
get a new commandline option to be able to access the metadata and
a special utility was added for other applications. If you look
at windows you will see that you need to use a filename like
<realfilename>:<streamname>:$DATA (which obviously does not work for
single-character filenames).

Ignoring samba for a bit which just needs streams to stay compatible
with windows I see few reasons for using streams:

* files are more complex these days and tend to include multiple
  different things: images with thumbnails and exif data, 'office'
  documents containing both text and images

* standard way to add common metadata to a file which can be used for
  searching tools (author, copyright, keywords, etc.)

But both can already be done in userland (modern image formats can store
thumbnails and exif data internally, applications use tar or zip-like
files for documents, etc.). The metadata part is a lot more complicated
as well since the behaviour of attributes might need to be complex:
if I change an image using an application that is not stream-aware, what
should happen to its thumbnail? 

The only common benefits I can see are standardisation and optimization:
instead of every file format or application defining a way to specify 
metadata for a file you get a common API defined by the OS (but you'll
still need to standardize on attribute names and formats, so plenty of
room that will still not help), and instead of parsing different files
or XML streams you can directly access a bit of metadata.

So far I'm not convinced that streams are worth the effort. Not that my
opinion is all that relevant here, but still :)

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.