At 11:00 28/10/2000, Hans Reiser wrote:
>Curtis Anderson wrote:
>
> > The problem with streams-style attributes comes from stepping onto the
> > slippery slope of trying to put too much generality into it. I chose the
> > block-access style of API so that there would be no temptation to start
> > down that slope.
>
>I understand you right up until this. I just don't get it. If you extend
>the functionality of files and directories so that attributes are not
>needed, this is goodness, right? I sure think it is the right
>approach. We should just decompose carefully what functionality is
>provided by attributes that files and directories lack, and one feature at
>a time add that capability to files and directories as separate optional
>features.
No, it is _not_ goodness, IMHO. - If you did implement the API for
attributes through files and directories, then what would you do with named
streams?!?
You can't possibly have both using the same API since you would then get
name collision on filesystems where both named streams and EAs are
supported. (And I haven't even mentioned EAs and named streams attached to
actual _real_ directories yet.)
Let's face it: EAs exist. They are _not_ files/directories so the API
should not make them appear as files/directories. - You have to consider
that there are a lot of filesystems out there which are already developed
and which need to be supported. - Not everyone has their own filesystem
which they can change/extend the specifications/implementation of at will...
Just my 2p.
Regards,
Anton
--
"Education is what remains after one has forgotten everything he
learned in school." - Albert Einstein
--
Anton Altaparmakov Voice: +44-(0)1223-333541(lab)
Christ's College eMail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Cambridge CB2 3BU ICQ: 8561279
United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
