Curtis Anderson wrote:
> > So it's not clear how you reached to the conclusion that directories
> > shouldn't be pressed into service as compound files. I'm sure you have
> > a reason, but it wasn't revealed here!
>
> It's an aesthetics argument. There are no new features in a directory-based
> streams-style attribute mechanism over basic filesystem semantics. It would
> be bad to confuse things by trying to say that this is "new" or "different"
> when it is not.
>
> The argument is also recursive, although I didn't bring that out in my
> email. Once I have such heavyweight streams-style attributes, maybe I
> need to store some additional pieces of information about that stream.
> For example, if I have an audio clip attribute where I say "My name is
> Linus and my OS is called Linux", I still need to know the encoding format
> and bit rates to reproduce the accent correctly. I've now claimed I need
> attributes of attributes, possibly with ACLs, timestamps, etc, etc. This
> is really just a call for hierarchically organized information, ie:
> directories and subdirectories. Which is again, what we have now.
>
> 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.
Could you please produce a more substantive argument. :-) You are
making an excellent argument in favor of doing exactly what you seem to
oppose.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
