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
|