On Tue, 23 Mar 1999, Ted Lemon wrote:

> > Also, the opaque data starts with a magic number, so that different
> > applications (users of the data) can tell if a node has their data or not.
> > Also, the magic numbers are reserved both normal and byte-swapped, so that
> > applications can tell if the opaque data is theirs from an opposite-endian
> > machine. :-)
> 
> Why not just require the magic number to be in a particular byte
> order?   This seems like the same amount of work for the application,
> but doubles the magic number space.

Because then applications have to keep all of the data payload in a
particular byte order. Half of our architectures (or there abouts) would
then all have to always byte swap. This way an application only has to
byte swap when reading in opposite-ordered data. My expectation was that
it would then just save the data in its native format, so next read
deson't have to swap. :-)

The magic number is a 32-bit integer, so we have tons of space. :-)

> Also, why not have a magic-number,length header, and define a standard
> way for applications to add their own stuff to this "resource fork"?
> It doesn't seem like it would be much work, what you're doing now is
> the simple case of it, and it seems like it would be potentially quite
> winning.

Because we really didn't want to stick a whole resource fork in. As MacOS
has shown, it takes a lot of work to get right. We didn't have the energy
and resources to do a full resource fork. :-(

The main thought was to just add enough space to let stacked fs's be able
to store data in a node, so that they can preserve state cleanly.

A MacOS resource fork fs could certainly come along and sit on an ffs, and
add resource fork functionality. :-)

Take care,

Bill