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.
"Extended" is a nice sounding synonym of "incompatible", just ask Micro$oft.
It does sound like goodness, but it is also very problematic and dangerous
to change the implicit assumptions that decades of software have been written
to assume. If you add an interface without changing the fundamentals, then
older apps can run without change. If you change the fundamentals, then they
break in mysterious ways.
> 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.
It all depends on how optional things are, and what differences an unmodified
app sees. IMHO, "none" is the right answer in this case. Part of my believing
that directory-hack stream-style attributes are not good is that I don't know
how to do them without making visible changes in the semantics of existing
objects. Proposing examples on how to make these extensions transparently to
existing apps would help.
> 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.
I have no objection to your agenda except that I believe the onus is on you
to show why it would be a good thing to go that direction. Can you say more
about why such an approach would be valuable for the rest of us? Good reasons
to keep it cleanly set theoretic would help a lot.
Thanks,
Curtis
--
Curtis Anderson, Storage Architect [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
