Right, as promised last night, here is an overview of the design of the installer project in general.
As I said way back(!) in January, the stated goal of this project is to offer a software delivery method that is as independant of the platform it is installing the software to as possible. Hopefully, I have designed a model that does not only that, but can also prove to be extensible, customisable and usable in more ways than the traditional "download and double-click" method.
One of the decisions I made early on at the start of this project (or rather, this incarnation of it) is that in order to be a truely platform independant distribution method, I would need to avoid as much platform specific information as possible in the file the user interacts with. The key as I saw it would be to take a largely meta-data approach, and let this be interpreted in a platform dependant manner using a native application type.
In this way, we save the overhead and stew of adding bootstraps for each platform in the file. Of course, there is the initial overhead cost of distributing the runtime to each platform
So like the RPM, YUM, DEB and MSI formats, the installation file is not in itself an executable file (well, MSI kinda is - AFAIK it contains a bootstrap that checks to see if the Windows Installer service is installed, and can optionally contain the runtime in case it isn't, but now I am getting beyond the point), but instead assume the role of a data file.
The Installer File
In the process of creating an installer, the developer will create at least two different files. The first is the file that contains all the information about the program - the metadata, the binaries, the settings and the dependency information.
It consists of a compressed archive, with a heading XML sheet (encoded as UTF-8) that acts as the information base for the image.
Files can be grouped into components of an application, for example the application data, the help files, example files, etc, and each of these can have a default weight that will determine whether they will be installed by default. All Images will have at least one component, that being the application data. This component is unique in that it will have a reserved name (all other components can be named as you wish), and it will be assaigned the weight of the primary component. Unless already installed (as in the case of a Repair), the user will not be presented with an option not to install it.
Image files have the file extension ".image".
The Install File
The second file is the installer file itself. Like the image file, it is an archive file with a UTF-8 XML header sheet. Images are assaigned weights to determine their importance to the installation in question.
All installers will contain at least one image, that being the store of information about your product. This is assaigned the weight of being the primary image. There is only one such image, and the installer file is named for it. Like the primary component in the Image, the user will not be presented with an option to not install the primary image, unless it has already been installed.
Install files have the file extension ".setup".
If you want to use a programming analogy, you can think of image files as being classes, and installer files as a namespace.
Q: Why the seperation?
There are a couple of benefits of seperating images from the actual installer profile.
* It makes it easier to incorporate third party dependencies in your application. Suppose you have written a package that requires the GTK+ Toolkit for Windows to be installed. By having the image seperate, you can easily incorporate different packages in your application without a need for a working knowledge of how they should be installed. It also has the effect of making it easy to share frameworks and other dependency methods that install themselves properly on the target system.
* Helps make the installation seamless. All images that have been selected to be installed are queued one after the other, so when one image has been recreated on the client machine, the next one will begin processing immediatly, all within the same viewport. Contrast this with current graphical installers, where running a second installation invariably means opening a new set of windows that clutter the users workspace.
* Reduces overall overhead. Queued images that run inside the same process reduce overhead incurred by other graphical packages that start a new process for each package to be installed.
* From a developmental point of view, it abstracts the distinction between a network installation and a local one. The same image can be used in either instance, all that changes is the address type used. The installer will be able to take the appropriate action when it comes to process the images.
So, what does everyone make of it? I know is a bit of a departure from most current installation models, but I don't think it does anything that puts anyone too far out of their way. In fact, I hope that it will help to make distributing software over a number of platforms (or even just the one) easier for both the developer and the end user.