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