Path: utzoo!attcan!uunet!mcvax!kth!draken!tut!tucos!abo.fi!vinsci
From: vinsci@abo.fi (Leonard Norrgard)
Newsgroups: comp.sys.amiga
Subject: Re: More 1.4 whishes
Message-ID: <5899@abo.fi>
Date: 2 Mar 89 20:22:35 GMT
References: <5442@abo.fi> <413@antares.UUCP>
Organization: Abo Academy, Finland
Lines: 65

In article <413@antares.UUCP>, jms@antares.UUCP (Joe Smith) writes:
> In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes:
>>Maybe now is the time to say what I want in 1.4 instead of asking why the
>>things aren't there when it comes.
>> ...
>>- An autoexec-directory: execute all programs and scripts in this
>>  drawer on startup. Then I would only have to drag icons into this
>>  directory to make them part of my startup.
> 
> If this is implemented, make sure it doesn't have the same problems as the
> AUTO folder on the Atari ST.  Several initialization programs will not work
> unless they are executed in a particular order.
>...

  VMS fixed this by adding a command called synchronize. At boot time, the
idea is that you submit jobs to the batch queues and of course some of them
are dependent of others. Ie. most will need to wait for the job mounting all
the disks etc. Since the batches run as separate processes, the task of
synchronize is to wait for another batch job to complete. Well, that's VMS.

  On the Amiga, a different approach must be taken since most of the startup
is obviously performed in the context of a single process. Thus, the startup
code would have to determine the right order of execution *before* the
execution begins. This could probably be achieved in many different ways
of which one is outlined below.

  In a reasonably well equipped Amiga system, the user will have multiple
applications, harddisks, extra hardware etc. Each may require its own
startup code, and some will need to wait for others to complete before they
are run. Some bigger applications may even need multiple scripts to that are
to be performed in a special order. Usually, applications needn't know of
each other, and thus doesn't need a mutually specific execution order.

  So how can we specify the order? We already have the #?.info files available
from the icons we drag into our autoexec directory. The icon system have
provisions for adding text into the tooltypes array of the icon. So by placing
directives about the dependancies and execution orders here, the startup
code would only have to read the .info files. That's cheap  --  it doesn't
have to do a contextswitch form one scriptfile to another just to check
their possible relations. The output of the .info scan would be an ordered
list of files to execute.
  So what would the directives look like? Well, how about:

     ANYTIME   --  Execute me at any point relative to the other startup
		   scripts in this directory, except for the FIRST script
		   which will always be the first. If no other type is
		   specified, ANYTIME is the default.
     AFTER name_of_other_script  --  Execute me sometime after `name_of_-
		   other_script' has been executed, not necessarily directly
		   after it. AFTER FIRST isn't needed as ANYTIME already
		   specifies this.
     FIRST     --  Obvious meaning. Only one of these in the directory though.
		   ANYTIME scripts will be executed after this.
     SLAVE master  --  This is a slave script of the `master' script. As
		   such, it is the `master' script's job to execute this
		   in a way chosen by the master script.
     
  While at it, please enhance the "tool types" gadget of the info program
to a couple of lines, it seems more and more programs get configured this
way, with more and more parameters to set.

  Comments?

-- 
Leonard Norrgaard, vinsci@abo.fi, vinsci@finabo.bitnet, +358-21-654474, EET.