This page

This page currently lists unsorted ideas for the WG. We will organize them as we work.

Why this WG?

Easy installation.

Cleanup unused files.

Complete unistallation of a product is needed to legally resell it.

Keep system tidy.

The process

Use the word "package" instead of "application" ?

The main act of installing an application should be copying or unpacking it to a directory on the system. The application should keep all of it's files in this directory, excluding shared files like shared libraries and offered files like fonts, but including libraries and fonts used exclusively by the applications.

Suggestion: Default destination should be the largest disk on the local machine.
Suggestion: Destination should always be chosen by the user from the list of available drives.

Is it possible to distinguish which drives are local? The default destination should be a drive that exists. Should we be able to define multiple default destinations for different types of packages in preferences?

The installer

Ask first, then install. Separate installer-engine, script and UI.

Idea: Let the installer generate a dos-script that is executed after the questions are ready. This allows for expert users to look through it before running it, and the script can be saved for later inspection. It can also be used again, if the same installation is to be performed again, after a crash or on another machine with identical setup.

Delayed replacement

Problem: If you install a package that updates files that are in use you get an "Object in use" error.

Should we offer "delayed replacement" of files? This will have to be done in the startup-sequence, pretty early.

User-levels

The installer should have settings for control over each action and the installation as a whole. The settings "Novice", "Intermediate", and "Expert" user allow for the user to control no, some, and all actions the installer does. The settings "Minimum", "Custom", and "Full" allow the user to choose what of the package he wants to install.

The user should be able to change his competence level (Novice, Intermediate, or Expert) during the installation, like with a menuitem.

Destination

Suggestion: The installer should always ask the user where to put a package.
Suggestion: The installer should alway inform the user where it has put a package.

Adverts

It should be possible to show animations and pictures and play sound etc. during an installation. This should not be a required part of the installation and it should be possible to turn it off as a temporary and permanent option. This does not need to be an installer library feature, rather an install-ui feature.

Suggestion: The user should be able to set different options for adverts, not just on or off. The options may include 'Default', 'Show Static Logo', 'Show Program Tips', and 'Entertain Me', with invalid choices being grayed out. Each advertizing-part of the install-script must then be marked by its type. The user could also choose which datatypes he would like to see: pictures, animations, sounce, music, etc.

Tools

A tool for creating installer-scripts would be extremely handy.

Uninstall

It should be possible to remove the application completely from the system, including shared files, env-settings, and user-startup entries. The main part of uninstalling the application should be deleting the directory it was installed in.

The installation logfile should aid in unistalling the application. Or not. Discussion needed.

Replaced files should be backed up as an option. This enables the installation to be rolled back if it fails. How long should this backup be kept? How about a general "version control" tool to let the user/administrator swap between different versions of shared files? No good? This way you never actually delete older versions of shared files, and you can revert to older versions if the newest has a bug. An even newer version with the bug removed would be even better, though.

Shared files

Notes

No central hold-all register! If information is stored, make sure it can be integrated into a future more general information-storage, ie. applications announce their type and abilities.

The psystem shoulf utilize file-tracking (what's the correct expression?) but must not rely on it since files can be deleted on other platforms by moving the HD or using removable media.

The phrase "shared file" means a file required by an application which can also be used by another application. This does not include files which an application offers, but does not require, such as fonts and datatypes. Typical shared files are libraries and devices.

The phrase "offered file" means a file offered by the application which other applications can also use. Typical offered files are fonts. Offered files should have a separate tool for unistalling, like a font-manager for fonts.

A used-count for shared files is needed to determine if any applications need it.

Problems

Shared files used by an installed package are deleted, leaving the packages unusable.
Deleteing a package leaves unused shared files on the system. This is just a problem if the files annoy the user, like making directory-listings take a long time, and fill up the HD.
Deleteing a package is not registered by the system.
Shared files required by "old-style" applications are not counted and can be deleted even if they are needed.

Solution: Group-based filing system

How can this solution be used on alien filesystems like FAT, HPFS, and NTFS?

Solution: Portfolios and Application List

A "portfolio" file is kept in PROGDIR: listing all the required files the application(s) in this drawer needs. The number of files listing a shared file as required equals it's used-count.

The portfolios

Mypackage

work:apps/mypackage/mypackage.portfolio:

package mypackage

source mycd:english/install

requires file libs:asl.library

requires file classes:tapedeck.gadget

user-startup entry priority 0

;BEGIN mypackage

assign mypackage: <install-dir>

path mypackage:bin add

;END mypackage

Utils

work:utils/utils.portfolio:

package utils

requires file libs:asl.library

requires file l:kcon.handler

requires file c:list

Util 1

work:utils/util1.portfolio:

package util1

requires file libs:asl.library

requires file l:ahi.handler

Util2

work:utils/util2.portfolio:

package util2

requires file libs:asl.library

requires file devs:scsi.device

The application list

Basically the application list can be placed in sys:db/applist:

mypackage 2.1 (1. january 1998) work:apps/mypackage

utils     1.0 (8. august 1988) work:utils

util1     43.2 (13. january 1998) work:utils

util2      1.36 (13. march 1998) work:utils

system     4.0  (1. october 1998) sys:db

orphan     4.0  (1. october 1998) sys:db

A subset of this list should be on every device. This would allow for quick registration of packages on removable media. If a disk is mounted which does not include an applist, the user should have an option of scanning the disk to create an applist for it.

Used-count

The used-counts for the shared files are:
libs:asl.library 3
classes:tapedeck.gadget 1
l:kcon.handler 1
c:list 1
l:ahi.handler 1
libs:asl.library 1
devs:scsi.device 1

Notes

The system (installer ? ) can check if all the required files for an application are present at any time. This is good if the application requires files it does not install itself. The installer can check if the required files are present in the system before copying/unpacking the package.

A tool for editing the portfolio and applist files are needed, although the syntax should be simple enough for advanced users to edit by hand.

"Old-style" packages

A file sys:db/orphan.portfolio contains requirements for files required by "old-style" applications and files the user wants to keep even if they are not currently used by any application. The tool for administrating the shared files should be aware of this file and treat it as a special file for storing orhaned shared files. It could also be in sys:storage/<something>

System files

A file sys:db/system.portfolio contains requirements for the OS. The files included here do not have to included in any other portfolio.

Using s:user-startup

The application list could be s:user-startup. We have entries for applications bordered by ";BEGIN <package>" and ;END <package>". We could add

;mypackage 2.1 (1. january 1998) work:apps/mypackage

or the like. It would save one file, making it easier to find what you are looking for. Using entries as above, s:user-startup becomes the applist. The sublists for each device would efectively become the s:disk-inserted script, if there was one.

It would also be possible to use a registration command like this:

;BEGIN mypackage

loadportfolio work:apps/mypackage/mypackage.portfolio

;end mypackage

This way the application can also be registered in an IPC environment. Another advantage is that s:user-startup will get smaller since the actual commands for assigns, path, etc. are in teh portfolio. The ";BEGIN" and ";END" are not needed since each package inserts just one line in s:user-startup. They can of cource be kept for compatibility..

Solution: Keeping shared files local

Let the system find the file even if it is placed in the applications drawer. The system must search all possible drawers and determine which file has the highest version. This requires changing of the loading routines for libraries, devices, classes, etc. A significant advantage is that all files for a package is one place. A disadvantage is that there will be many copies of a file on the system. Removing a package may also remove the file with the highest version, forcing other packages using the same file to use older versions. This approach also only works for known filetypes unless the loading process is chaneged to include in what directory in progdir: a file of a certain type is to be found.