lkml.org 
[lkml]   [1999]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Summary of how linux can best avoid the need for streams
Richard Gooch writes:
> Hans Reiser writes:
> > Richard Gooch writes:
> > > Hans Reiser writes:
> > > >
> > > > I am not saying put an FS into a file, I am saying make the filesystem
> > > > effective enough that nobody needs to create things like structured
> > > > storage. Given that as a goal, what is needed?
> > >
> > > I don't even concede this goal. In some cases "structured storage"
> > > inside a file is quite reasonable and efficient.
> >
> > We disagree.
>
> 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.

I don't understand you. I advocate using directories not streams. You
advocate what?

>
> > > 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?
>

When a file body contains a reference to another file, and the filter
replaces that reference with the contents of the other file in response
to a read request.

> 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"?

Resource Description Framework
http://

>
> > > > * 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.

Microsoft integrates features of the gui into the kernel, you advocate
integrating features of the kernel into the gui, sigh.

All aspects of naming should function completely independently of the
gui. They are orthogonal OS components.

>
> But absolutely no way should the kernel/libc translate directory-based
> albods into pseudo-files.

I don't understand you, except that I think you know how you have seen
it done, and think that the way it has been done must be the right way.

>
> > > > * 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 :-)

Power users will love it. If I implemented it only in the gui, then I
would have only gui users who can use it.

>
> > 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.

I suppose that when I introduce database style views (think clearcase,
but clean), you'll really hate that....

Regards,

Hans

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.070 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site