Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!asuvax!ukma!usenet.ins.cwru.edu!agate!twinkies.berkeley.edu!lippin
From: lippin@twinkies.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: To be or not to be a resource.
Message-ID: <1991May7.024914.5522@agate.berkeley.edu>
Date: 7 May 91 02:49:14 GMT
References: <8FmJ25w163w@shark.cs.fau.edu>
Sender: root@agate.berkeley.edu (Charlie Root)
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 29

Recently jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) wrote:

>With the limitations of the resource fork, and the expense of the
>Hunk Manager, has anybody come up with a simple way of storing
>variable-length data items in the data fork?

To my knowledge, no one has come up with a generally useful answer to
this question.  I think the reason is that the way your program uses
the file is strongly reflected in the efficiency of the various
methods.

In general, make the file structure match the way you use it.  If you
have a collection of independent things, a single global map is
generally a good idea.  If the items in the file have some structure,
you'll do well to mirror the structure in your file format.  If the
items split into fixed-size groups, you'll likely want to manage each
size individually.

As you know less about the contents, the problem becomes more akin to
heap management, and most elementary CS books will tell you six
different ways to manage a heap.  The difference to keep in mind is
that a file isn't as close to random-access as a heap -- a free space
map will work much more quickly than a linked list of free blocks.

					--Tom Lippincott
					  lippin@math.berkeley.edu

	"It's a poor sort of memory that only works backwards."
					--Lewis Caroll