Messages in this thread | | | Date | Sat, 26 Jun 1999 12:27:33 +1000 | From | Richard Gooch <> | Subject | Re: albods are not a clean set of orthogonal primitives |
| |
Michal Jaegermann writes:
> NeXT is using a very simple minded, not to say trivial, meta-tag. > This is simply an ".app" suffix on a directory name. It may be not > good enough on a long run but it worked quite well for a while and I > do not recall this to be ever a major concern. It is true that > command line tools allow you dive in directly into "app folder" and > you have to use GUI to see it as a whole. Actually even GUI has a > non-default option to "open app folder as a directory" and > manipulate files inside. And, contrary to what some people were > saying in this thread, this is a GOOD THING (TM). This capability > is not used directly very often but sometimes, when is needed, is > invaluable.
I couldn't agree more. I just don't see the need for all this complexity. The job of the FS is to provide efficient storage of user data. Directories and files do this nicely. The kernel has no business in interpreting that data. Storage belongs in the kernel. Interpretation belongs in the application/library.
At the lowest levels, (kernel, libc and standard tools like tar, cp and mv), interpretation is not appropriate. These are raw interfaces and should remain so. Hacking libc to add automagic interpretation is just as bad as hacking the kernel.
Presenting user data objects as directories is not a new thing, and it works quite well. Users get used to the idea of having to save a dataset with tar or "cp -r".
If you are convinced that the users are so dumb that they can't cope with "cp -r" instead of "cp" to copy a dataset, then you're talking about a class of users who *won't* be using the command line at all! You're talking about users who will only use a GUI. And once you realise this, you also realise that the whole "problem" is one that can be hidden in the (new) GUI.
All you really need is a library that all applications that require support for "data forks" can link to. This library is also used by the common desktops and file browsers, so you can choose your interface but share the functionality.
I can't see any need for any changes to the kernel, libc or system utilities which introduce new semantics. If there are any changes, they should be in the area of optimisations (like reiserfs) which can store and lookup many small files efficiently.
And besides, application writes who want to store ancillary data should serioursly consider whether a "data fork" is really the right approach. Putting a linked list of objects inside a file is not a big deal. Once you've got the library to handle the grunt work, it's trivial for the application.
The only time it makes sense to put data forks into separate files is when more than one of those data forks is large and grows, or the accumulated size of small growing data forks is large. The definition of "large" is currently a few MiB. Tomorrow a few MiB will be seen as "small".
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/
| |