> I have a message pending (I just need to type it) on why ChangeSets may not
> be the answer.

It's sort of how I started out with Oasis... I just wanted a place to dump code where I could look at it
without it causing trouble for my image.  Later on I made that into a place where I could compile the code,
instantiate objects, and interact with them, without clobbering my image.  Which sounds very straightforward-
but nothing that I did in Oasis was easy to accomplish.

What I found as I built Oasis was that there were very deep-seated non-modularities permeating everything.
It's not just the tools, or even the code, but perhaps even more significantly, the attitude.  Everything
*knows* that there is only one namespace.  That was true, of course, an entirely reasonable assumption at the
time.  But that means that there are much bigger mountains to move ( forget about getting to do something as
easy as climbing them ) than you may be thinking.  To give an example- In Oasis, I can load the entire class
library for VisualWorks into a single module.  There you have all the code in one module, just like it wanted
to be.  But... you can't use it, because you can't initialize this class library- over 200 classes need to be
initialized, but the code to do it trips over itself... if I remember correctly, it went something like this:
can't initialize Object, because Collections are initialized... can't do Collections, because something else
isn't ready... Symbol and String are cyclicly dependent on each other, neither can proceed...  The issues go
deeper than just having some mechanisms like namespaces.  "Just add namespaces" will not solve these problems.

As a counter-example, I *can* load a modified version of PocketSmalltalk's class library into a module, and I
*can* instantiate and interact with objects defined by PocketST's classes.  The reason is simple- I *can*
initialize PocketSt's class library, because it was designed to be brought up from scratch.  So, this is the
route I would pursue, given that I already have Oasis- construct a class library similar to PocketSt's, but
using Squeak's code ( I'd just use PocketSt's, but I don't believe it is open-source, though I could easily be
wrong about that ).  The benefit of such an approach is that I have a very clear picture of just what I have
in the module, and whether it works.  The hurdles I would have to overcome are that I would have to be able to
generate Squeak's bytecodes, ( meaning that I might have to either port Squeak's parser and compiler to
VisualWorks, since that is where Oasis lives these days, or run them on top of PocketSt inside Oasis, which
I've explored a bit in the past ), and I would have to know how to generate a new Squeak image from scratch.
Both of these things are justifiable extensions to the existing Oasis capabilities, as far as I'm concerned,
so I'd be willing to give it a try if someone will tell me what I need to know about the image formats, and
what the VM expects.

- les