Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!chroma.UUCP!bryan
From: bryan@chroma.UUCP (Bryan Ford)
Newsgroups: comp.sys.amiga.tech
Subject: Idea for program start-up (long)
Message-ID: <0873.AA0873@chroma>
Date: 13 Jun 89 11:25:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 65

I just had an "incredibly brilliant" idea (in other words, probably dumb
:-), on program start-up.  Every computer I've seen, including both micros
and mainframes, allows you to have a special command file that is run on
startup.  On the Amiga this is called the Startup-Sequence.  However, there
are problems with this method of getting programs started.

It's ugly.  Unless you're some structured programming fanatic, your
Startup-Sequences are not going to look all that beautiful.  This is
complicated by the fact that that different programs take different startup
options in different ways, and it can get real ugly trying to give every
program the startup options it needs.

It's hard to pass configuration parameters to the program.  Usually you end
up using SetEnv, a configuration file in S:, or icon ToolTypes.  Using
SetEnv makes the Startup-Sequence even uglier, a config file in S:  makes
the S:  directory (which, by the way, is *supposed* to be reserved for
scripts) uglier, and using ToolTypes require you to keep an icon around
(and ugly up your directory), even if you never use WorkBench.

It's hard for programs to modify it.  I have yet to see a program try to
install itself in the user's Startup-Sequence (upon the user requesting it
do so, of course).  This is because there are so many places the file could
be inserted, but only a few of them will work, and those few will be very
different for every user.  For example, I'm sure some people still use the
single 1.2 Startup-Sequence.  The program would have to be sure and put
itself before the LoadWB and EndCLI, but after everything else.  For 1.3,
things get more complicated, with two different startups.  Sticking it in
the Startup-Sequence probably wouldn't be a good idea, because nothing else
has been set up yet.  It would have to trace the chaining of the scripts
into Startup-II, but be able to recognize not to go into a Shell-Startup or
something that gets run more than once.

So you see the problem.  Now for my idea to fix it.  Make a "sister" of
Mount, which, instead of starting up devices, it starts up resident
programs.  It could use a "Devs:StartList" or something, which would look
very much like a MountList.  Then a program called "Start" traverse the
StartList, starting all the programs that need to be started.

The StartList could have options that go with each program that is started,
and Start would pass those options to the program the way it wants them
passed (Unix-style switches, AmigaDOS-style arguments, whatever).  The
advantage to this is that all the options are in the same place, and they
are easily edited with a normal text editor (no searching for config files,
or having to load WorkBench to change some ToolTypes).

Additionally, this would be easy for programs to change.  Just append its
own setup file to the end, possibly allowing the user to change the startup
options from within an installation program.  It could even search the list
for an entry for itself, in case the user just wants to change some of the
options or remove the entry.

Ideally, this Start program would be an ARP program, and there would be
routines provided in arp.library which could allow programs to add, change,
or delete entries in the StartList.

Of course this couldn't be used for some parts of the Startup-Sequence like
conditionally copying things to RAD: or whatever.  However, it would get
Startup-Sequences down to size, and it would be great for "normal" users.

Note that this is not a standard specification or anything, just an idea to
think about and play with.  Criticisms welcome, flames ignored.

Have fun!

				Bryan