Hi


Considering the discussion so far I would like you to emphasize
two  aspects:


1) What does the user expect?

Let's take my expectation as an example:

If I download Squeak and get a base image of a relatively 
moderate size and a repostiory of additional modules I can load 
to have a customized image I would be happy with that.

Some sample application configurations could be

- Basic Morphic system for the use as a small utility program
  which can be easily shared
- PDA image with PDA applications
- Multimedia authoring system
- Presentation system (like a powerpoint viewer)
- Basic Morphic system with sample applications / projects
- Swiki server
- Image with Unicode additions
- Image with aspect oriented programming additions
- Basic Morphic system with OODatabase
- VM development system

I think a base image size of 3MB would be fine: It would fit on one
floppy when zipped. This means simple applications can easily
be shared. (I now that many systems already have a CD-Writer built
in, but many don't have one and for a PDA 3MB is fine as well).
For more comprehensive images I would see no problmes
of dealing with images of 10..20 times this size. A large configu-
ration could for example include alot of sampled musical instruments.
The iMacs currently sold have a base memory of 128MB.

The benefit for the user is to save time configuring his image
for a particular need. The monolitic image approach SqC has the
big advantage that an image contains all the necessary things.
Having a relatively small base image and add-ins keeps this 
approach while at the same time allows more flexibility to adapt
for particular needs.


2) Feasability
Instead of having a relatively large image and then a 'majorShrink'
method I would say having the base image and some predefined 'loadConfig' 
methods would already be a big step forward. 
It probably still means a lot of work to implement and test.

Using 'majorShrink' means a lot of tampering and is not easily done. 
The result is difficult to test.

As the StableSqueak team already has a preview solution with a base image 
and a repository in place I would like to see this applied to Squeak 3.1a 
main stream as well.

Dan mentioned he would like to see a solution happen in September. 
This kind of solution could be possible I imagine.

Having a full fledged system with packages, name spaces, dependency
detection would be a considerable effort and has a lot of side effects
which are not easily to deal with. The above mentioned proposal does
not exclude efforts in this direction in the future. But in the sense
of 'do the simplest thing that possibly may work' I would favor a 
moderate step at this time.


Cheers
Hannes Hirzel