Jan Bottorff wrote:

> [... lots of good points regarding application dependencies...]
>
> So what do others think about the tradoffs of dynamic component updating
> (with potential version skew nightmares) vs. a closed "static" universe we
> call an application. I could image there might be some sort of shared
> component version control that could provide the best of both worlds.
>
> - Jan

That shared component version control is something I've been dreaming of for
quite some time. Imagine the following:

   * Every app is composed of versioned components, some of which may be
     shared, others may be private to the application.
   * If you install an app, only those components (and component versions)
     that you don't already have are installed on your system. A component
     version is never being overwritten by another (newer or older) version.
   * The configuration of each application (its composition of individual
     component versions) is accessible to the user, so he may try to see
     whether the app works with his newer, better, faster versions of
     components as well. Of course, configurations are versioned as well, so
     you could go back to an older working config if you find your newer does
     not really work.
   * All components have an internet repository where you'll find all versions
     of that component, bug and change records and compatibility information.
     These infos are organized in a database that can be browsed by a human
     (e.g. via a web browser) and can as well be used by tools to analyze a
     given configuration for potential problems. I could also imagine having
     some sort of distribution mechanism such that the repository is not
     centralized.
   * Components can be automatically or manually upgraded to any (newer of
     older) version via the network. The system determines which components
     need actually be fetched to perform an upgrade.
   * You'd need some sort of component responsibilities such that new versions
     are made available at a reasonable rate. Maybe there should be a way to
     start side-tracks of a component with your own version numbering, so you
     could improve on a component and share your improvements even if the
     original author does not think they're worth integrating into the main
     line.

Much of this sounds a lot like ENVY On The Internet. Yes, I think that's close
to the idea. You might not like ENVY but when it comes to configuration
management it's quite good in my opinion, so it's probably not a bad model to
consider. However, I think that its concept of class definitions and
extensions is too limited for the kind of distributed component sharing I
envision. My current favorite model (tentatively named 'Layers' or 'Collage')
goes like this:

   * All code in a Smalltalk image is organized in layers which correspond
     roughly to change sets, components or ENVY applications. Layers are
     ordered in a stack, with higher layers overriding lower layers where
     appropriate.
   * Every layer can not only extend lower layers by adding methods (like ENVY
     class extensions) but can apply any kind of change to the lower layers,
     much like a changeset can, but in a more orderly manner. Conceivable
     changes could be:
        o Addition, replacement and removal of methods
        o Addition and removal of instance or class variables
        o Addition and removal of classes
        o changes in the superclass hierarchy
   * Layers can include configuration information about required layers (and
     maybe their versions) or known problems concerning coexistence with other
     layers.
   * Changes in one layer which were overridden in another are not lost. When
     a layer is written to a file, all its definitions are included, and not
     definitions done to the same classes or methods in other layers.
   * Layers can be reordered within the stack, possibly making changes visible
     that were masked by higher layers.
   * Layers can be activated and deactivated atomically, perhaps in groups to
     avoid inconsistent intermediate situations.
   * More than one version of a Layer can be in the image, but only one
     version can be active at any time.
   * Layers can be stored and loaded in a binary format for fast application
     import.
   * Layers might be the basis for Squeak applets if the client has a base
     library already on disk. You could also construct runtime images by
     loading layers into an absolutely minimum image, or via a modified system
     tracer (like VisualAge does it).

The reason I would call this 'Collage' is that it allows the masking and even
removal of parts. This is in contrast to ENVY, which works more like a jigsaw
puzzle where the pieces must not overlap.

Of course, there are lots of unresolved questions with the model. For example,
how should consistency errors be handled when layer A defines an instance
variable, layer B defines a method which uses it, and layer C removes it
because it has changed the class so that it's not really needed anymore.
Another question is how the namespace problem should be solved (perhaps by
making each layer a namespace and allowing layers to import and export names).

Yet another open issue is how 2 applications should live together which
require different versions of the same component. I'd say that these two
cannot coexist in one image, so the VM should maybe be able to handle multiple
images (probably sharing the components which are the same), or it must be
able to start up more that once (currently not possible on the Mac).

The real big problem is that I don't hve the time to write such a beast, not
even to spec it completely... So if you have some free time and would like to
make me happy, start coding :-)
If not, we can at least talk and dream about it...

Hans-Martin