Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brand.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!sdcrdcf!oberon!brand!barad
From: barad@brand.UUCP (Herb Barad)
Newsgroups: net.micro.mac
Subject: Re: HFS problems
Message-ID: <197@brand.UUCP>
Date: Wed, 2-Apr-86 13:56:30 EST
Article-I.D.: brand.197
Posted: Wed Apr  2 13:56:30 1986
Date-Received: Tue, 8-Apr-86 05:49:29 EST
References: <184@tekchips.UUCP>
Reply-To: barad@brand.UUCP (Herb Barad)
Organization: U. of So. Calif., Los Angeles
Lines: 46

In article <184@tekchips.UUCP> chips@tekchips.UUCP (Chip Schnarel) writes:
>I finally decided to read the instructions.  RASCAL has anticipated the problem
>and has implemented a workable solution.  Put simply, there is a string
>resource which tells the RASCAL compiler where the libraries are.  Just edit
>the resource to give the explicit location of the library folder.  RASCAL now
>works fine.  I have one minor complaint: the "path" search string should be
>part of the configuration dialog.
>
>Example:
>    Libraries:SomeVolume:SomeFolder:SubFolder:LibraryFolder
>    Utilities:SomeOtherVolume:DifferentFolder:FolderInFolder:...:UtilitiesFolder
>
>Now Unix hackers will tell you, correctly, that it is bad practice to hard
>code this sort of info into the application.  What happens when you run the
>app. on another system with the Libs in a different place?  Here is a use
>where resources show thier strength!  The info is not "hard coded in" it is
>an editable part of the application configuration.  A reasonable solution I
>believe.
>
>Now some controversy:  Should the form of these "path" resources be STANDARD?
>I think so.  Perhaps there should be a PATH resource type. On the other hand,
>STR seems to work just fine.

I think that this approach is a good idea.  Maybe a PATH resource in
the system file (one that could easily be installed by unsofisticated
users using some "PathEditor" application (i.e. don't force everyone
to use ResEdit - some people will panic).  Many applications can look
to see if a PATH resource is defined for whatever it needs.  Perhaps a
PATH can be define for include files (for compiler applications).  Or,
a PATH might be defined for other types of data files that an
application might need.  This would allow a user to structure his/her
HFS to their liking.  If a PATH is not defined, then look in the root,
some default directories, or in the current directory (more throwbacks
to Unix).  A PATH resource would be just one more way to allow (but
not force) user's to customize their systems.

-- 
Herb Barad	[USC - Signal and Image Processing Institute]

USENET:

...!sdcrdcf!usc-oberon!brand!barad			or
...!{lbl-csam|trwrb|trwspp}!trwspf!herb			or
...!{lbl-csam|trwrb|trwspp}!trwspf!brand!barad

ARPANET:	barad%brand@usc-ecl.ARPA