[Cuis] InstallStream 1.0

Cuis2.0 from Juan Vuletich is showing the way towards the goal of working with a relatively small kernel image as the starting point, to build evolutionary and revolutionary new Smalltalk platforms. (e.g. Morphic3)

A true kernel image need have no package or source code management tools out of the box, nor does it have network protocols loaded.

The idea of InstallStream is to enable the simplest possible mechanism that could possibly work, for a broad range of tasks.

1) Loading kernel updates.

2) Publishing and collaborating on kernel fixes for approval and inclusion in the release image.

3) Publishing and maintaining personal collections of fixes.

4) Publishing and collaborating on specific kernel innovations.

5) A very simple means to publish and reload mini-packages so that more can be removed from the kernel

6) Publishing sequences of monticello packages and fixes to load and use tools/frameworks e.g. Seaside

7) Building derived images using all of the above

8) Capturing exactly the content and installation process of a derived image for customisation and cherry picking.

The existing updates stream mechanism consists of a single numbered series of changesets, serially applied to improve the released image.

"to load these updates"

 

Personal Kernel Fixes and Personal Application Fixes

An IS may be used as a collection point for personal local fixes, and as a publishing mechanism to share fixes with others, and to nudge them upstream to the kernel maintainer.

Similarly an IS may be used by a group to collaborate on a suite of fixes, such as an audit of mathematical functions provided by the kernel.

An IS may be used to publish, collaborate on, and subscribe to optional features to the kernel, or prospective upgrades, such as Traits, or a Namespace implementation.

In connection with an existing application-framework such as Seaside, an IS may be used to manage local patches required by that application-framework (applied prior to loading the application), or local patches to that application itself after it is loaded.

In addition an IS may be used to provide the equivalent of packages, but with less imposed structure. 

And finally IS may be used to deploy sequences of existing monticello packages, to install applications such as Magma or Seaside.

When Monticello or a package management system is used to load a number of packages, the record of the exact installation process is not kept in a manner which is then easily available for use by others. 

"Installer" is one option for sharing install procedures, since it is used to write scripts for loading packages in a specific order, after which scripts may then be exchanged, and customised.

Using IS to organise packages for loading into a base image, the directories of files are in themselves the record of exactly what was loaded and in which order.

Thus when updates.webapp.seaside3 is published for Cuis using Bazaar, and you check it out locally, it comes with all the chosen packages in the appropriate order. You may branch it if you need a custom version, and when you publish your application, it may be published with the whole updates/installs build tree, since the build tree is the documentation of what happened in which order to build your application, ripe for cherry picking, or branching by any other subscriber.

Within existing package managers, the idea that there are explicit dependencies between packages is used to provide a safe load order.

IS does not have this mechanism, instead, the system is considered to have a layered architecture, and packages are published with respect to a specific layer. Notably they may be subscribed to at a different layer if required.

The basic layering is provided by a dot notation, in the directory name.

Within each layer there are packages which provide a base framework, and packages which use the base framework. So we may optionally use alphabetic sorting to provide explicit load ordering subdividing the layers further as follows. (from top to bottom)

Ordered Pre-Layer 2 - /updates.02-network-http

Ordered Pre-Layer 2 - /updates.01-network-sockets - the digits are used to "sort first"

You can have as many layers as you wish and IS is agnostic about how the layers are used, apart from the bottom layer 0. This is the default, a re-implementation of the updates directory of old, which may be used in any manner that the kernel maintainer wishes. Note there is no "pre layer 0".

We may define the layers by commonly accepted and useful norms like so: (bottom to top)

1a. kernel  - the absolute minimum e.g. compiler in /updates

1b. core     - a working minimum e.g. /updates-morphic /updates-collection

2a. system - interfaces /updates.00-sockets

2b. system - tool and service frameworks /updates.network /updates.toolbuilder

2c. system-extensions - services servers e.g. /updates.network-smtp

3a. application frameworks - e.g. Seaside

4. Generic Application Development

updates.webbapp.seaside.store

In conjunction with Bazaar (or other scm tools) IS can provide the basis for a "trunk for kernel images", in which both parallel (the old 3.11 process) and sequential (the new trunk process) approaches may be combined.

I think that Cuis2.0 is poised ready to make great strides.

best regards

Keith

postscript:

1. InstallStreams may be used to tidy and trim Cuis2.0 further, if Juan adopts IS for himself for loading his favourite bits and pieces.

3. Loading Monticello into Cuis