Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!intercon!amanda@intercon.uu.net
From: amanda@intercon.uu.net (Amanda Walker)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Config File Resource Blues
Message-ID: <1169@intercon.UUCP>
Date: 12 Jul 89 02:46:14 GMT
References: <7953@hoptoad.uucp> <7930@hoptoad.uucp> <2013@dogie.macc.wisc.edu> <1165@intercon.UUCP> <1168@intercon.UUCP>
Sender: news@intercon.UUCP
Reply-To: amanda@intercon.uu.net (Amanda Walker)
Organization: InterCon Systems Corporation
Lines: 40

In article <7953@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes:
> True, most configuration resource files can be expected to be small.
> However, many others have no real limit on size except for the limits
> of the Resource Manager itself.  For instance, suppose that information
> on computer accounts for a terminal emulator are stored in the file.
> The user may add any number of resources.  This is the kind of file I'm
> more accustomed to dealing with.

That's a reasonable point, and I have in fact used similar techniques
myself from time to time, using a resource file as a sort of quick-and-dirty
tagged data file.  However, once it gets to any real size, I'd say it's
time to use a different approach to the problem, either by splitting things
into more than one file (say, a settings file and a "Accounts" file for your
example) or not using the Resource Manager at all.  One of the problems with
doing quick-and-dirty stuff is that users then take the program and stretch
it until it breaks.  As Apple says, the Resource Manager is not a database.
The Finder Desktop file is a prime example :-).  Great on 400K floppies, but
then people insisted on using it on big hard disks...  I tend to be
paranoid--I figure if users can add an infinite number of custom resources,
they will :-).

I'm very glad that Apple is putting a standard, supported B-tree manager
into System 7.0.  It's about time!

> [accidental writing into application resource fork]
> This can be gotten around in a number of ways.  Probably the best is to
> use a Get1Resource rather than a GetResource. [...]  For all I know your
> actual code may take care of this problem, but your pseudocode didn't
> address it.

Quite true, as a couple people have pointed out in mail.  My actual code
does indeed use Get1Resource for just this reason, but I forgot to put
that into my posting.  That'll teach me to post an outline instead of
pasting in known working code :-)...

--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net  |  ...!uunet!intercon!amanda