In article ,
Andre G. Isaak wrote:


Unfortunately Apple has abandoned
this idea and settled for the lowest-common-denominator approach, and
w're all the worse off for it.

yep.

Educate me. What's the advantage of the "forks"? As described, it looks
like metadata with a fancy name, apparently conceived as attached to or
pointed to by the file. Presumably it's stored separately from the file.

Resource Forks are completely unrelated to metadata.

The 2-fork architecture was inherited from Classic Mac OS, and, while
still supported by mac OS X, it is used much less frequently.

In Classic Mac OS, every file consisted of two separate forks (either of
which could be empty).

The Resource Fork contained structured data which was managed by the
operating system which defined a wide variety of resource types (though
applications could define there own). These included GUI elements like
menu templates, window templates, dialog item lists, icons etc. as well
as things like fonts, device drivers, executable code segments, keyboard
layouts etc.

The data fork contained anything the application which created the file
wanted to put there and the application was responsible for interpreting
and organizaing that data.

Metadata wasn't stored in either fork. It was stored in the desktop
database which was maintained by the finder.

a good summary.

The advantage of the resource fork was simply that it made the mac much
easier to program since datatypes used by the OS were entirely managed
by the OS rather than the application (and it made it easier to
customize the GUI of existing applications).

it also meant that end users could easily modify existing apps (or even
the system itself) by modifying and/or replacing resources, and in some
cases, add (or remove) additional functionality.

The majority of files which one would actually want to distribute
cross-platform would have only a data fork as files which made use of
the resource fork were generally mac-only files anyways. The bigger
problem back in the day was transferring mac files to another mac across
another system (Windows, *nix, etc.) which didn't recognize the resource
fork.

true, although standard file types (text, jpg, etc.), often stored
extra stuff in the resource fork alongside the file data, including
window size/position, scroll position, zoom level, etc., and if that's
lost when transferring to another system, no big deal. it just uses the
defaults.

all three parts (data & resource forks plus finder info) could be
combined into a single entity (macbinary) so that it could be hosted on
non-mac system without losing anything which was normally done
automatically by mac comms software and generally where compatibility
issues arose because that blob was no longer a standard jpeg, text or
whatever format anymore.