[comp.sys.mac.programmer] An idea for handling read-only and shared applications

dce@Solbourne.COM (David Elliott) (09/05/89)

There was recently a discussion of why it is wrong to write back
application resources and data for the purpose of configuration, since
the application may be shared or read-only.

The problem with this is that this is one of the areas that makes the
Mac so nice as compared to, for example, X applications, which are
configured via a configuration database which must (at least for now)
be changed by the user).

It seems to me that there ought to be a way for programmers to take
advantage of this useful aspect of the Mac file model without breaking
things.  So, I have the following suggestion.

To "install" an application on the local disk, the user runs a program
which copies the resources used by the Finder (ICN#, FREF, BNDL, and a
few others) and other programs to launch the program.  The program asks
the user to locate the "real" application to be lanuched (this could be
on the hard disk, a CD-ROM, a floppy, or an AppleShare volume), and
stores this information in a resource.

A special CODE resource would be added to the installed application,
which would, when executed, cause a Resource Manager patch which would
cause all resources to be loaded first from the installed application
and second from the "real" application (asking for the required volume
to be mounted if needed).  All modifications would be made by writing
to the installed application.

The result is that those parts modified in the course of using or
configuring the application are kept locally, and the parts never
changed (most CODE, DLOG, DITL, ICON, etc. resources) are obtained from
the unmodified original.

This has a number of advantages:

1. Easier programming.  You don't have to worry about where to put
   configuration info.

2. Infrequently-used applications can be put on read-only floppies
   to be loaded as needed, instead of on the hard disk, where they
   take up room.

3. Backups of modified applications would only save changed resources,
   and not the CODE and other large resources that are stable.
-- 
David Elliott		dce@Solbourne.COM
			...!{uunet,boulder,nbires,sun}!stan!dce

"We don't do this because we love you or like you...we don't even know you!"