Curtis Anderson wrote:
>
> 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.
So really your logic supports not having a common extended attribute API but having
each fs do it
its own way. This is okay with me.
>
> > 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.
I have a really long paper under the Future Vision button at www.devlinux.com. A
shorter one that
is more focused on why you shouldn't create pointlessly different interfaces to
objects with
different syntaxes would be Pike's "The Hideous Name" which is in the bibliography of
my white paper
under the white paper button.
>
> 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]
