Apple _could_ have reserved one resource type or a number of them for
usage by the Finder (not: OS) to store things like icon position, etc.
just like they reserved the resource type CODE for executables and the
whole BNDL mess[1][2] for icon information.
Re-tinking about that, I suspect that another reason is that the
original Mac was not slow but slooooooow, and many open files and many
GetResource() calls for displaying a directory window was simply too
much overhead. This is also the most probable reason for the desktop
file in which the BNDLs were copied.
> the resource fork is fully as part of the data file as the data fork and
> only the application has the right to play with it. One could argue that
> it's not really metadata at all, but a database "view" on a file.
Right. It _is_ a file with a specialized DB structure.
The distinction between metadata and application data is a bit blurred
here, however. Look at TEXT files by programs like BBEdit, which are
pure ASCII files in the data fork and carry attributes in the resource
fork. You can FTP the file as TEXT and get a text file - still usable
but without any font/style information. This is application-specific
metadata, so to speak. OTOH, BNDLs are carried by the application, but
they are pure metadata in the sense that only the Finder uses them,
and only for UI purposes. The program still runs when you remove them
(except for cases where it uses its own ICN#s of course).
> So I guess another question is, what kind of metadata are we discussing
> here? Do we want to be able to store the resource fork of a Mac file in our
> metadata so as to present a Mac-like abstraction of a file for use in a
> theoretical Appleshare-type package?
Unnecessary, there are already Un*x Appleshare servers which store a
Mac file as three files (the atomicity concerns are addressed by the
server application here, which has the exclusive right to access its
directories).
For database-structured application files, we have user space
libraries. (ICN#s or STR#s in applications can go into their own ELF
section, etc. - just need an appropriate linker.)
> Or do we want somehting like OS/2 EAs
> which are specifically metadata for use by the shell/file manager?
I think this is more what's needed. E.g. we have enough graphical file
managers on Un*x but they are all unusable because of the simple fact
that you can't move the icons around in a window and they stay where
you put them (although this is arguably stuff for a dot-file in the
respective directory). Think about file comments, etc.
olaf
[1] It took many, many years before they came up with a version of
ResEdit that could properly handle that particularly braindead
structure, and figuring it out by hand was a "challenge".
[2] Any real reason for that "have BNDL" flag out there?
-
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/