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

Perhaps I'm a bit to negative tonight (see my previous email, I appologize
in advance), but IMHO this is just a dream because - well, the only
explanation I've is that in the past there wasn't the readiness to
implement a component system, probably because of the history of Smalltalk.
 The needed technology has already been developed for other languages for
year.  Perhaps it was the delusion to have the perfect system already, I
don't know.

>   * Every app is composed of versioned components, some of which may be
>     shared, others may be private to the application.

Hans-Martin made a number of very good suggestions.  I'll try to separate
them in suggestion I consider essential and others, which can added upon
them. 

IMHO, these are the essential concepts:

1/ Components, which publish an interface description plus id to
   uniquely identify them.

2/ Name spaces, which assure that components don't affect each other.

3/ A Registry, which keeps track of loaded components and which can
   install and uninstall components (and as an addon also update them)

If anybody knows COM, this should sound very familiar. But as I said, it's
nothing new.  You've just to accept that components will restrict the
changability of Smalltalk.

>   * 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.

An app (which need not but should be a component) will query the Registry,
using the well known ids of the needed components.  There's no need to
version components.  If you like, read the technical papers about COM
(there're really good, even if they're from Microsoft :-) about the problem
which are introduced because of versioning and that even versioning doesn't
solve all problems.  So every release of a component will get a new id.
Using GUID (global universal IDs, hugh 128-bit monster numbers, which can
be created uniquely universe-wide) we can assure that there are never ever
two components with the same id. If you change just a single bit of your
component's interface, you must release a new component with a different ID.

(It might be possible to allow small bug fixes, but strictly speaking even
these small fixes will obviously change the components behavior and
therefore would require a new ID.  Fixing these bugs without announcing
them actually introduces the problems, Microsoft still have with COM. All
other problems are caused by the poor capabilities of DLL which are used to
implement COM components and aren't a flaw of COM)

So the app will check for the needed components (actually it will require
the existence of certain interfaces but we can ignore this to reduce the
complexity) and the registry might either automatically load or download
them or at least warn the user (which is probably a programmer in this
scenario) about the absence.

>   * 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.

I don't like to idea to immitate ENVY's (a commercial version and
configuration management tool for VisualWorks or VisualAge Smalltalk)
micro-versioning. Actually I'd prefer the way VW uses parcels or you'd use
change sets in Squeak. Freeze a compontent's interface, but don't require
to version everything.

>   * 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.

This is an addon IMHO. A component provider can't be forced to make sure
that his component will not break other components.  The component
framework has to assure this.  Even the dumb programmer shall not easily
break other people's code.  Smalltalk's meta programming of course always
allows to create the biggest imaginable damage, but this shouldn't be the
default.

Any component has to live in its own name space.  It is not allowed to
modify other components (which especially includes the base image
components) code. A component even may not add methods - this is a
difference to - say - parcel, which should be also available, as we'd get
them for free.  A few day ago, I already wrote about what I think a parcel
or modul is all about.

The only way, a component can interact with your application is through an
interface object (some instance of any class which is required to provide
the guaranteed methods)

The other way (did I say only above :-) is to import classes into your name
space, that is you'll tell your application which name shall be used to
address the components class.  This should be reduced to a minimum as now
these class names belong to the components interface and must be provided
for ever.

Using the interface object as a factory for other object seem to be the
better idea IMHO.

>   * 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.

Automatic update also means automatic bug propagation. Optionally is okay,
but I'd prefer to disable this feature.

>   * 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

You cannot force to component provider to release updates once per month.

>     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.

As a component is a black box, you cannot start your own side-track of
other components.  The right way is to create your own component based on
delegation. Again, see the discussion of COM for more advantages.

To ease the work, I strongly suggest to extend smalltalk to support true
delegation.  As I already tried, this is trivial to implement.  I added a
delegation primitive and also changed the compiler to accept
  resend.abc
as an alternative to
  super abc
and
  xxx.abc
as the expression to use the object stored in slot "xxx" as the root for
the lookup of method "abc", which is then executed in the context of self
and not in the context of xxx as it would happen if you use
  xxx abc

>Much of this sounds a lot like ENVY On The Internet. Yes, I think that's
close

And this frightens me.  While I actually like ENVY for the most time, I
don't think that this is the perfect tool. From the UI point of view, it's
actually a mess and an example for bad usability design.  When I use ENVY,
I always feel like a SMA-L-TKR clone of the Paranoia role playing game (if
you happen to use this.  All clones live in an underworld ruled by the
all-powerful computer and are forced to tell anybody "the computer is your
friend.  Help the computer, respect the computer.  Otherwise, you're a
traitor and you must be terminated)

>   * 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.

This should be possible with parcels or modules, but not with components,
as this breaks all encapsulations and includes strict dependencies, for the
order of load, for example.

>   * 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.

....as with VW parcels...

>   * Layers can be reordered within the stack, possibly making changes
visible
>     that were masked by higher layers.

well, that might be tough.

>   * Layers can be activated and deactivated atomically, perhaps in groups to
>     avoid inconsistent intermediate situations.

A must.

>   * More than one version of a Layer can be in the image, but only one
>     version can be active at any time.

Why? Just keep them all in your file directory/repository/ftp
server/whatever.  Try to think (what an intriguing idea) that your image is
not the world ;-)  All you need is to be able to load and unload them.  And
don't forget the feature to _re_load a module, as the Objectshare people
did with their parcel concept.  This feature is essential for team
environments.

>   * Layers can be stored and loaded in a binary format for fast application
>     import.

....and in source format of course...

>   * 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).

As they violate encapsulation, it's again impossible to keep more than one
in one image without further preparation. Therefore, I'd perfer to restict
something like applets to components.

>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.

Just forbid them.  Sounds too restictive at the moment, but I think, too
much freedom can be as harmful as too less freedom. The problem is to find
the right middle-way.  Therefore I propose three concepts for three
different needs.

1/ You can modify and experiment as always without modules or components
2/ You can use modules to structure your work and allow better distribution
   some some problems you might decide to life with.
3/ You can provide safer components which eventually allow to assemble
   applications without problems.

>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).

Yes.

>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

This is no problem with my concept, as there aren't two version of one
component but two different components which reside in different name spaces.

>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).

Too difficult for too less value for this specific problem IMHO.

>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 :-)

:-) Same with me.

>If not, we can at least talk and dream about it...

Yeah!


bye
--
Stefan Matthias Aust  //  Are you ready to discover the twilight zone?