Doesn't a stack-based  model like Collage presume a sequential form of 
development? The earlier discussion dealt with parallel and 
independent developments. How would the Collage model deal with 
this?

Ivan


> 
> --------------B706DF04F43580B7FB34CE62
> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854";
> x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit
> 
> Hi folks,
> here are some of my ideas on source code management and working together
> in Squeak. Maybe this could be the basis for a better modularization and
> configurability of Squeak images.
> 
> Hans-Martin
> 
> Hope you can manage the HTML. Netscape is fairly good at producing an
> ASCII version, so I just send both formats.
>   ------------------------------------------------------------------------
> 
> Collage - A Source Code Management System for Smalltalk
> 
> These are my ideas on a novel way of organizing Smalltalk applications
> such that they can be versioned, easily loaded into and unloaded from a
> base image. This is inspired partly by my daily work with VisualAge and
> ENVY, partly by earlier work on a source management system that we
> developed at Georg Heeg (AppMan). Some of the ideas come from what these
> systems don't do but should. -- Hans-Martin Mosner <hmm at heeg.de>
> 
> Note: The following text is written as if this system existed already.
> Don't be fooled, most of it is still fantasy!
> 
> Collage
> 
> I start by highlighting some of the features of traditional Smalltalk
> source code management systems. In the beginning, there was the .st file
> and the ChangeSet, and this is what we Squeakers still live with.
> ChangeSets and .st files are a good way of organizing small packages which
> can be loaded on top of a mostly clean image. Their bonuses are:
> 
>    * .st files can change any aspect of the system, just as interactive
>      development could.
>    * ChangeSets are small and non-intrusive
> 
> However, they do have some problems:
> 
>    * Only the fact that something was added, changed or removed is kept,
>      not the actual source
>    * Unloading is not possible
>    * Versioning is not supported
> 
> Larger Smalltalk projects are mostly done using the industrial-strength
> ENVY systems. If you know ENVY, you know what it's great plusses are:
> 
>    * Proper version and configuration control
>    * Source sharing in a team
>    * Fast loading and unloading of applications and configurations
> 
> However, it also has some shortcomings:
> 
>    * It is big
>    * Changing (fixing) system classes is difficult
>    * Applications can not overwrite methods or class definitions from
>      other applications
> 
> You could compare the way an ENVY Smalltalk image is built to a jigsaw
> puzzle: All the parts have to fit together, but they must not overlap.
> This works fairly well for closed projects where you can assign the work
> to different people, and they can talk about overlaps and possible
> redundancies to sort them out. For independently developed applications
> and base fixes, this is much more difficult. Collage, on the other hand,
> is designed around the metaphor of a stack of overlapping layers, which
> may partially or completely mask underlying layers. Elements in collage
> layer are a superset of the things that can go in a .st file or ChangeSet:
> they may be a class or method definitions, changes or removals etc. But
> Collage elements could also be inst var or class var additions, removals
> or renamings, class renamings, pool and pool var definitions. In the case
> of conflicting definitions, the uppermost layer wins. This is just like
> the way .st files work. But you can reorder or even uninstall layers,
> thereby unmasking previously masked definitions. Collage layers can be
> loaded and unloaded quickly by using the ImageSegment technique for
> storing complex structures in a binary file.
> 
> The Collage system within a Squeak image has a stack of top-level
> layers.
> Top-level layers constitute packages or applications. They should be
> mostly independent. Possible prerequisites should be stored as Gossip
> items (see below). Top-level layers have an internal collection of
> sublayer which constitute the different patch levels of a layer. Whether
> top-level layers should have major versions remains to be decided;
> probably they should, especially when forking for parallel development and
> bug-fixing is desired. (In addition, loading 100+ patch layers might be a
> little slow). Sublayers can contain the elements listed above, plus some
> internal changes such as undos of elements defined in a previous sublayer
> of the same top-level layer.
> 
> Collage layers can be loaded into an image without installing. There
> exists a mechanism to execute any number of layer
> installations/uninstallations/reorderings atomically, which would make it
> possible, for example, to switch between alternative compatible
> implementations of system-vital packages.
> 
> Gossip
> 
> In addition to the stable versions of applications, you need
> meta-information which probably emerges only after an application has been
> versioned and released. This includes known bugs and incompatibilities,
> prerequisites, documentation etc. The main difference to the normal
> textual bug information is that Gossip items have a formal structure,
> which makes automatic reasoning possible. Gossip items have authorship so
> that you can probably weight them according to the people who wrote them.
> There would also be some sort of second-level Gossip, which probably
> supports, refutes or revokes earlier Gossip when more information becomes
> available.
> 
> SCAN
> 
> The Squeak Comprehensive Archive Network would be a number of WWW
> servers (probably modified Swikis) which mirror Collage and Gossip items
> and serve them in different formats:
> 
>    * Downloadable Collage files for loading Collage layers into an image *
>    Downloadable Gossip files for off-line analysis and decision about
>      which layers you want to load
>    * HTMLized version of Gossip files for on-line lookup and search
> 
> Collage and Gossip files could be digitally signed by their author to
> avoid problems with tampering. Some way of uploading must exist for
> authors to get their stuff into the SCAN.
> 
> 
> --------------B706DF04F43580B7FB34CE62
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Hi folks,
> <br>here are some of my ideas on source code management and working
> together in Squeak. Maybe this could be the basis for a better
> modularization and configurability of Squeak images. <p>Hans-Martin
> <p>Hope you can manage the HTML. Netscape is fairly good at producing an
> ASCII version, so I just send both formats. <br> <hr WIDTH="100%"> <h1>
> Collage - A Source Code Management System for Smalltalk</h1> These are my
> ideas on a novel way of organizing Smalltalk applications such that they
> can be versioned, easily loaded into and unloaded from a base image. This
> is inspired partly by my daily work with VisualAge and ENVY, partly by
> earlier work on a source management system that we developed at Georg Heeg
> (AppMan). Some of the ideas come from what these systems don't do but
> should. <br>-- Hans-Martin Mosner &lt;<a
> href="mailto:hmm at heeg.de">hmm at heeg.de</a>> <p>Note: The following text is
> written as if this system existed already. Don't be fooled, most of it is
> still fantasy! <h2> Collage</h2> I start by highlighting some of the
> features of traditional Smalltalk source code management systems. <br>In
> the beginning, there was the .st file and the ChangeSet, and this is what
> we Squeakers still live with. ChangeSets and .st files are a good way of
> organizing small packages which can be loaded on top of a mostly clean
> image. Their bonuses are: <ul> <li> .st files can change any aspect of the
> system, just as interactive development could.</li>
> 
> <li>
> ChangeSets are small and non-intrusive</li>
> </ul>
> However, they do have some problems:
> <ul>
> <li>
> Only the fact that something was added, changed or removed is kept, not
> the actual source</li>
> 
> <li>
> Unloading is not possible</li>
> 
> <li>
> Versioning is not supported</li>
> </ul>
> Larger Smalltalk projects are mostly done using the industrial-strength
> ENVY systems. If you know ENVY, you know what it's great plusses are: <ul>
> <li> Proper version and configuration control</li>
> 
> <li>
> Source sharing in a team</li>
> 
> <li>
> Fast loading and unloading of applications and configurations</li>
> </ul>
> However, it also has some shortcomings:
> <ul>
> <li>
> It is big</li>
> 
> <li>
> Changing (fixing) system classes is difficult</li>
> 
> <li>
> Applications can not overwrite methods or class definitions from other
> applications</li> </ul> You could compare the way an ENVY Smalltalk image
> is built to a jigsaw puzzle: All the parts have to fit together, but they
> must not overlap. This works fairly well for closed projects where you can
> assign the work to different people, and they can talk about overlaps and
> possible redundancies to sort them out. For independently developed
> applications and base fixes, this is much more difficult.
> <br><b>Collage</b>, on the other hand, is designed around the metaphor of
> a stack of overlapping layers, which may partially or completely mask
> underlying layers. Elements in collage layer are a superset of the things
> that can go in a .st file or ChangeSet: they may be a class or method
> definitions, changes or removals etc. But Collage elements could also be
> inst var or class var additions, removals or renamings, class renamings,
> pool and pool var definitions. <br>In the case of conflicting definitions,
> the uppermost layer wins. This is just like the way .st files work. But
> you can reorder or even uninstall layers, thereby unmasking previously
> masked definitions. <br>Collage layers can be loaded and unloaded quickly
> by using the ImageSegment technique for storing complex structures in a
> binary file. <p>The Collage system within a Squeak image has a stack of
> top-level layers. <br>Top-level layers constitute packages or
> applications. They should be mostly independent. Possible prerequisites
> should be stored as Gossip items (see below). <br>Top-level layers have an
> internal collection of sublayer which constitute the different patch
> levels of a layer. Whether top-level layers should have major versions
> remains to be decided; probably they should, especially when forking for
> parallel development and bug-fixing is desired. (In addition, loading 100+
> patch layers might be a little slow). <br>Sublayers can contain the
> elements listed above, plus some internal changes such as undos of
> elements defined in a previous sublayer of the same top-level layer.
> <p>Collage layers can be loaded into an image without installing. There
> exists a mechanism to execute any number of layer
> installations/uninstallations/reorderings atomically, which would make it
> possible, for example, to switch between alternative compatible
> implementations of system-vital packages. <h2> Gossip</h2> In addition to
> the stable versions of applications, you need meta-information which
> probably emerges only after an application has been versioned and
> released. This includes known bugs and incompatibilities, prerequisites,
> documentation etc. The main difference to the normal textual bug
> information is that Gossip items have a formal structure, which makes
> automatic reasoning possible. Gossip items have authorship so that you can
> probably weight them according to the people who wrote them. There would
> also be some sort of second-level Gossip, which probably supports, refutes
> or revokes earlier Gossip when more information becomes available. <h2>
> SCAN</h2> The <b>Squeak Comprehensive Archive Network</b> would be a
> number of WWW servers (probably modified Swikis) which mirror Collage and
> Gossip items and serve them in different formats: <ul> <li> Downloadable
> Collage files for loading Collage layers into an image</li>
> 
> <li>
> Downloadable Gossip files for off-line analysis and decision about which
> layers you want to load</li>
> 
> <li>
> HTMLized version of Gossip files for on-line lookup and search</li>
> </ul>
> Collage and Gossip files could be digitally signed by their author to
> avoid problems with tampering. Some way of uploading must exist for
> authors to get their stuff into the SCAN. <br>&nbsp;</html>
> 
> --------------B706DF04F43580B7FB34CE62--
> 



Ivan Tomek,

Jodrey School of Computer Science
Acadia University
Wolfville,
Nova Scotia, Canada, B0P 1X0

fax: (902) 585-1067
voice: (902) 585-1467