SAIM Proposal
Idea:
Provide a mechanism to create an ADP which installs a (small) AOLserver application. All files etc. should be included in the ADP. The user copies the ADP into his pageroot, opens the page in a browser, posiibly fills out some configuration data and clicks "install" after which he is redirected to the running application
Motivation:
Provide a simple way to package applications for AOLserver, thereby lowering the amount of time a (new) user has to invest to get a useful instance of AOLserver up and running. This would go hand in hand with the proposed Batteries Included binary distributions.
Design:
I'm not too sure about this yet. I have a prototype which does little more than read a "spec file", base64 encode the files specified in the spec, wrap the base64 encoded files with some TCL to unpack and copy them to the right locations on the server and a simple form, that asks the user under what url prefix he'd like to be able to reach the application.
The big decision here is how to make the packaging step general enough to be useful for most people but not too general that you end up duplicating the same code for every application and a hand crafted solution would be less work. From my viewpoint there are two main ways to structure the whole process. A declarative way telling an installer engine which files of what type there are and what config variables the user should provide. The second way is an imperativ approach, where all we provide are some fairly general functions to pack/unpack files, copy them to specific locations, ask for certain config variables etc. and leave the actual work to small TCL bits the person packaging the applications has to write using these functions.
Both approaches have their merits. The declarativ way is definently simpler to handle but also less flexible, if a certain feature is not implemented, your out of luck. The imperative way gives the packager maximum flexability but requires more upfront work.
Unresolved questions:
- How are config variables passed to the application? -- Olaf
Dossy 2005apr11: I think the debconf style of adding "magic comments" around the config section for the app in the config file could be safe. This way, the app could rewrite the config file (after taking a backup copy) to update settings for the app in question. Ideally, each app's configs would live in its own Tcl file, and all the app would do to the main config is add a line like: "source /path/to/appconfig.tcl" on installation. All app-specific config. settings would be managed by the app in that appconfig.tcl file.
- How do we prevent/handle multiple instances of an application within one virtual server? - I think multiple instances are not the way to go, if you need this kind of functionality, your probably better of with OACS or require the whole instance for your application anyway. -- Olaf
Dossy 2005apr11: Yeah, this whole virtual server thing is just messy. Lets solve the problem for the simple case first, then see what real (not imagined) problems there are in the complex case. I bet if we drive to the simplest possible solution for the simple case, the changes required to accomodate the more complex solution will be possible.
- How are required database pools handled? Should the installer edit the nsd startup file (IMHO BAD) or require the user to manually create some pools from which the installer will let him choose one or more for the application. -- Olaf
Dossy 2005apr11: This config. stuff would also go into the appconfig.tcl file that's managed by the app. Perhaps we need a framework for building the install.adp as well as a config.adp that lets you modify some (but perhaps not all) settings set at install time.
- Upgrades? -- Olaf
Dossy 2005apr11: Again, lets solve the simple case (first install) then see what problems there are left to solve for the upgrade case.
Would anyone use something like this / is there any interest in something like this? What features to you see as essetional? What approach to specifiying the install instructions would you prefer?
Dossy 2005apr11: I'm in favor of a hybrid declarative/imperative approach: a config file that specifies what info. the installer must collect during pre-install; a list of files to wrap inside the installer, along with an (optional) post-install callback Tcl script to handle any app-specific customizations to the standard installer's behaviors.
