Hi andreas

I think that we should give a try. I have the impression that we get 
trapped into
the image concept. How other languages do? They have module 
load....stuff and the only thing
we can lose is the implementors or senders in external package (which 
could solve by having
a good package representation - easy to say not sure easy to do). This 
is clear that we should not have packages that are too fine grained but 
imagine that instead of having three images
we have one image but constructed from a mini image by loading package.

In VisualWorks this is working, I go on the store server or in the 
distribution directory and I load the parcel I want. When I use it I 
say may parcel/package requires this one. This was working in Envy for 
decades even if you could get lazzagna. So why Squeak is so special 
that it would not work. After we should not be silly to mix layers and 
create lazzagna (large spaghetti) but this should be feasible.

Imagine I could do (please don't tell me you can with shrinking, I try 
it on 3.2 where is was broken and this was a pain) PackageManager 
default unloadToCreateMiniImage, or PackageManager unloadToHaveNoMM.

We would have not different distributions but one that we could peel 
easily.

Stef



>> We do intend to have multiple images, starting soon - with 3.6's
>> release. This will include the "full" image, which I think everyone
>> agrees should be a "media platform", among things, since cool demos
>> pretty much require media stuff. This image would be "base" + a set of
>> packages preloaded. To avoid becoming a fork, this image
>> should try hard to include packages that are mostly modules.
>> It can apply patch packages, if it avoids patches to "base" stuff,
>> so that development done on this image is shareable with "base".
>> It would obviously need to be led by someone media oriented.
>>
>> Does this solve the part that bugs you specifically? if not, how?
>
> If I would think that having multiple images that way would solve the
> problems I wouldn't even have started the discussion. In short, I don't
> trust this approach very far though it is hard for me to explain 
> exactly
> why. Perhaps another analogy with the Linux world and its distros is
> appropriate. What you see is effectively a split of the community 
> around the
> different distros and in the Squeak case this might be even more 
> complex
> since it is likely that significant work will be done in the various
> versions.
>
> Consider a situation where we use a method in distro X which is not in
> distro Y (or implement a selector which is not in distro Y but defined 
> by
> someone else in distro X). What's going to happen? Stuff breaks. 
> Meaning
> that we'll soon have packages which work only for distro X, Y, or Z. 
> Meaning
> that the overhead which is required to make "all around versions" for
> something triples (this is similar to changing versions but now we 
> suddenly
> have a couple of versions which we need to test against). And I don't 
> think
> the community can survive this split (it's too small for it) and 
> people will
> see Squeak as a thing "where things just don't work" as a package 
> loaded
> into one distro works perfectly fine and breaks in another one. And 
> then,
> people will (merely to avoid this image) start thinking very hard about
> giving their distro a different name, setting up their own servers for 
> the
> packages and you got a couple of forks ahead of you. I'll leave it up 
> to
> your judgement if the Squeak community can afford this.
>
> Cheers,
>   - Andreas
>
>
>