3rd-party app dependencies

Marcel Weiher marcel at system.de
Mon Jan 11 23:45:57 UTC 1999


A couple of notes:

Yellow-Box frameworks implement a very lighweight yet quite  
functional version of these ideas, though for Objective-C living in a  
UNIX environment.  A framework is simply a package of code and  
non-code resources that live in a directory with a specified  
structure.  Major and minor revisions are supported and multiple  
revisions can be placed in the same directory (so installing a new  
version of a framework doesn't overwrite an old version).

Source code version and configuration management is viewed as a  
separate and in my opinion somewhat more complex issue.  Each  
framework is self-contained and not seen as a 'patch' to a monolithic  
base-system.  Rather, the system-provided base frameworks are seens  
as providing services for user frameworks.  Modifications to  
pre-defined classes are made using categories or posing without  
actually touching the base-classes themselves.

Marcel

> From: Hans-Martin Mosner <hm.mosner at cityweb.de>
> 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
>
>
>
>





More information about the Squeak-dev mailing list