I've seen it work. I don't claim it's the best general solution. But
it can and does work in some circumstances, and is favourable to using
directories.
> > However, I would agree that for some applications that FS-based
> > structured storage is much better than file-based structured storage.
> >
> > > I propose the following:
> > >
> > > * inheritance of file bodies
> >
> > What exactly is this?
So, what is it?
> > > * a syntax based on rdf for writing to files which have inheritance
> > > (solving this stumbling block was important for me)
> >
> > What's "rdf"?
Again, what's "rdf"?
> > > * filters, such that "dirname/..tar" generates a tar file when read,
> > > and "dirname/..cat" concatenates for read, and
> > > "filename/..filtername" runs filtername on the file/directory
> > > filename.
> >
> > NO! This is a terrible idea. The low-level tools *must* provide raw
> > access. This higher-level grouping of data belongs in the GUI.
>
> So you are saying that from an ascii terminal I should not be able
> to access these things?
No, I didn't say that. What I'm saying is that the most common user
who wants to see albods as atomic is sitting behind a GUI.
Command-line users who want to see albods as atomic can use some
special tools, or perhaps switches to existing tools.
But absolutely no way should the kernel/libc translate directory-based
albods into pseudo-files.
> > > * overloading directory names so that if they are opened as files they are
> > > files, and if accessed as directories they are directories.
> >
> > Again, NO!
> >
> > > All of these features are valuable in and of themselves.
> >
> > I strongly disagree. Some of them are good, some of them are not.
>
> Well, I guess it is time for me to write it, yes?
Sure. But I wonder how well it would be received in the developer
community, compared to a plain library that provided the functionality
on top of the existing raw interface?
I personally would not want to use such a system. I would however be
quite happy to use a GUI that makes things "easier", and some new
command-line tools or switches to existing ones.
You might win over GUI users, who would never notice the difference.
But power users will curse you. Actually, being Linux they'll develop
their own scheme :-)
> I appreciate your feedback.
You're welcome. I really appreciate your work on reiserfs. From what
I've read about it, it looks like the best thing since sliced bread. I
can't wait for it to go into the kernel and play with it.
But I really think any scheme that tries to pretend (at the lowest
levels) that directories are file is flawed. Not only does it
introduce complexities and compatibility problems, I fundamentally
think it is a *less* convenient approach.
Sometimes, you really want to get in at the raw interface and play
with things.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/