Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tekchips.UUCP
Path: utzoo!linus!decvax!decwrl!pyramid!hplabs!tektronix!tekcrl!tekchips!chips
From: chips@tekchips.UUCP (Chip Schnarel)
Newsgroups: net.micro.mac
Subject: HFS problems
Message-ID: <184@tekchips.UUCP>
Date: Mon, 31-Mar-86 14:22:36 EST
Article-I.D.: tekchips.184
Posted: Mon Mar 31 14:22:36 1986
Date-Received: Wed, 2-Apr-86 20:39:29 EST
Reply-To: chips@tekchips.UUCP (Chip Schnarel)
Organization: Tektronix, Beaverton OR
Lines: 60


There is an inherent problem with the new hierarchical file system (HFS)
Note: I say problem and not "bug".  What I am talking about is part of
what causes many programs fail under HFS, and that is the the nature of HFS
itself.  Let me explain, and in the end I want to offer a solution.

The reason for the HFS is to hide the number of files and file information
from the finder.  This is done both to organize files better and because
the finder has performance problems with more than a few files.  However, when
the file information is hidden from the finder, it is hidden from the
application as well.  This is what is causing us all the headaches.  Programs
can't find other files, libraries, resources that they need because the
information as to where the files are is hidden by the file system.

One solution to the problem is to make every program search up and down the
file folder structure until it finds the file or exhausts the system.  This
solution is not very efficient at best.

I ran across a better solution this last weekend when I attempted to get
the RASCAL programming environment to work with the new ROMs and my QuickDrive.
The first thing that I noticed was that the compiler could no longer find the
include (uses) files and that the linker could not find the libraries.  After
contemplating throwing everything into the root directory (yes, I'm going to
fall back to UNIX terminology.  The solution is borrowed from UNIX too.)
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.
Also some sort of relative addressing needs to be included.

Example:
    PrintFile:CurrentFolder:SomeSubFolder:TempFileFolder
	      ^^^^^^^^^^^^^--relative address
    PrintFile:ParentFolder:SomeSubFolder:TempFileFolder
	      ^^^^^^^^^^^^--relative address

Wild cards may also be useful.

OK, discussion time.  This is not my idea, but I think it's a good one.  Anyone
else have comments?
	
	Chip Schnarel
	...!tektronix!tekchips!chips