I advocate putting albods/data forks/streams/what-have-you into
separate files in a directory, and making no changes to the kernel or
libc. That means the default behaviour of the kernel, libc and system
utilities is that a directory-based albod is just another directory.
Other (optional) behaviour can be added on top of this.
> > > > 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.
I advocate putting features that don't belong in the kernel/libc
somewhere else than the kernel/libc.
> All aspects of naming should function completely independently of
> the gui. They are orthogonal OS components.
Keeping things out of the kernel doesn't mean you can only have them
in the GUI.
> > 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.
You're being offensive.
> > 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'll say it another way in an effort to make it clear. Put your albod
code into a library. Then write some new command-line tools, or extend
existing ones (as an option), to make use of this library. Also get
the GUI writers to use this library (again, an option should be
provided).
This way, *everybody* can see the cooked format (albod pretends to be
an atomic object like a file), and *everybody* can see the raw format.
If you stuff around with the kernel/libc, you make it hard/impossible
for people to see the raw components (real files in real directories).
I can't stress enough how wrong that would be.
> > 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....
I'd first like to see some clear explanation of why such a view should
be imposed, rather than made optional through some new utility.
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/