Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site spuxll.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!harpo!whuxlm!spuxll!ech
From: ech@spuxll.UUCP (Ned Horvath)
Newsgroups: net.micro.mac
Subject: Re: Music Works' Volume Control...
Message-ID: <658@spuxll.UUCP>
Date: Tue, 14-May-85 10:40:49 EDT
Article-I.D.: spuxll.658
Posted: Tue May 14 10:40:49 1985
Date-Received: Thu, 16-May-85 08:23:24 EDT
References: <5365@Shasta.ARPA>
Organization: AT&T Information Systems, South Plainfield NJ
Lines: 25

The attitude at least one correspondent takes -- read the volume control out
on every DA close, or even every systemclick -- is a bit naive.  The nature
of DAs as "asynchronous processes" makes it impossible to take account of
EVERYTHING they might do to you.

As a more extreme example, I am working on an application that maintains a
DeskTop image.  If you run the Extras DA you can delete a file.  Does this
suggest that I should rescan all volume directories on every system click,
just in case Extras or something like it removed a file?  Has anybody tried
doing this to FileVision (which retains 'back to...' in the file menu)?

Take a still more extreme example: postulate a DAMover DA.  Such a DA MIGHT
remove a DA from the System file.  So, I guess I had better reconstruct the
apple menu on every system click as well.  What have I missed?  An
irresponsible DA may clobber the System Font or one of my application fonts
on a system click...

How well will your last program run if some asynchronous process shoots out
its temp files on the fly?  Or overwrites them?  Do you recalculate
checksums on everything before you trust the data in the file?

You see the problem.  When is a "user-friendly" system allowed to give up
in the face of a hostile user?

=Ned=