Installer - Can we do better?

I post it here because I know I will get _lots_ of constructive feedback here. For those that do not wish to keep up with the discussion, but would like to see the results of it, a copy of this first post and a digest of follow-ups can be found at http://www.crusaders.no/Amiga/installer/

Responses can be posted in comp.sys.amiga.programmer or directly to me at donv@crusaders.no

Installer - Can we do better?

Here are some:

1. Installer gives the user a single focus for the interface
2. The interface is the same for all installations, it is recognizable.
3. Installer adds functionality through new commands like copylib etc.
4. It let's the user set how much control he would like: Beginner, Average, Expert.
5. Installer allows expansion by execution of cli commands

This is all very well, but there are some points which I really dont like. Here are some:

1. Installer uses it's own scripting language. Why?
2. The added funtionality like copylib etc. is not accessable by other programs.
3. The scripts cannot be localized in the usual way by adding a catalog file. You have to change the script.

So we have some good points, and some (in my opinion) bad points. Let's try to put them together by trying to eliminating the bad points without compromizing the good points.

There are a lot of issues not discussed in this post. Either I have not though of them :) or they would require a change in how Instaler communicates with the _user_. This discussion is about changes to the way Installer works "behind the scene". One improvement is listed below:

1. Improve the "Ask questions first, _then_ install" approach of Installer. This includes the ability to go back and change an earlier setting.

   As an example you may get several "Where do you want to copy/install this file/application?" questions, and on the last one you realize that you are out of space on the disk chosen. you would most often like to change the earlier answers so you can have all the parts of the installation on the same disk.

Eliminating bad points

1 - Installer uses it's own scripting language. Why?

I expect that someone will enlighten me on this subject.

I propose to use AREXX as the official installer scripting language. The new installer could be made to accept both the old format and the new by recognizing AREXX files by the '/*' at the beginning. However, one should consider making a new application as the successor of Installer that only uses AREXX to keep size down.

• Pros:
  • AREXX is the most used scipting language on the Amiga, and many know it already.
  • You dont have learn a two languages to make installer and application communication scripts, just one.
  • AREXX is more powerful than the Installer scripting language.
• Cons:
  • Old scripts will have to be recognized by the new Installer and we get an unnessesarily big application. A small price to pay.
  • Installer-scripts for currently developed software will have to convert the entire script to AREXX. Not _that_ big a job.
  • AREXX is a bit more complex, allowing for more programming errors. This is only an issue if you decide to use any of the features that AREXX has and the current Installer does not. You should not _have_ to use these features to get the same result in an AREXX script as an current Installer script, since the new Installer should deliver the same functions, and more.

2 - The added funtionality like copylib etc. is not accessable by other programs.

There are two ways to do this:

• Keep the function in Installer, and allow other apps to send commands to Installer's AREXX-port for execution. This could be done with or without a GUI. For AREXX-scripts, this is ideal, but it makes the use of the function from other apps more complex since you have to address an AREXX port just to execute _one_ command. This is solved by executing 'rx ' for each command if you do not wish to add AREXX-port communication to your application.
• Make an external (cli) command for the function. This gives instant access to the function for any app or script that can execute these, and simplifies the use from the shell. However it adds yet another file to the system, and one file per funtion in Installer would quickly clutter the directory listing. Also it makes communicating to a focused GUI more difficult (see discussion later).

3 - The scripts cannot be localized in the usual way by adding a catalog file. You have to change the script.

Adding a new language to the installer script needs a re-distribution of the entire script, and usually this means redistributing the whole archive.

A 'SetCatalogName' (or a much better name :) ) function in Installer combined with 'GetLocalString' (better use the same names as in Locale.library) adds localization easily. You then only have to distribute a new catalog-file to add a new language to the Installer-script.

Keeping the good things

1 - Installer gives the user a single focus for the interface
2- The interface is the same for all installations, it is recognizable

1. Send commands to Installer to be executed immediately possibly in parallel and independently from each other. All you have to do is send the command to Installer and it will be executed. You can choose to wait for completion and return value, or you can choose to continue if you don't want a return value. The commands are not guaranteed to execute in sequence if you choose not to wait for completion.
2. Get a process ID from Installer and send it as a parameter with every command to ensure that the commands are executed in sequence. You always wait for completion and always get a return value, even if you don't have to use it. You do not get a display.
3. Get a display ID from Installer and send it as a parameter with every command. You are guaranteed that the commands are executed in sequence, are displayed on the chosen display, and you always wait for completion and get a return value. Basically this is like the second option with a display.

3 - Installer adds functionality through new commands like copylib etc.

4 - It let's the user set how much control he would like: Beginner, Average, Expert.

1. If using the user-level dialog function the value the user chooses will be used.
2. The author of the script can set a minimum user-level, and a recomended user-level. These will be used in the user-level dialog as a lower bound and default.
3. The user-level is read from the 'sys/userlevel' environment variable. If the value is not set by the author of the script, and no user-level dialog is used, this value vil be used.

5 - Installer allows expansion by execution of cli commands

donV