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.
I would really like to keep a syntax that lends itself to a set theoretic approach so
that I can one
feature at a time make our FS into a set theoretic database. That is my hidden agenda
here: if you
clutter the basic concepts of filesystems it makes it more work to do a clean
extension of
filesystems into my pet novel theory for database semantics that is substantially
upwardly
compatible with filesystems. I REALLY want the more general approach for this reason.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
