Tim Rowledge <tim at sumeru.stanford.edu> wrote:
[SNIP]
> > [snip] But more importantly, you can no
> > longer find all senders and implementors of a class/method.
> So we need extended tools for this. We needed extended tools in the
> first place to even have the concept of looking for senders/etc by means
> other than grep. Life evolves. We get used to it or die out.
> > This makes
> > it hard to confidently make changes since you can no longer see all
> > dependent code.  With a full image, I find all dependent code and make
> > changes accordingly.  This allows me to make wholesale changes,
> > confidently.  I wouldn't be able to build a robust closure compiler if I
> > didn't have Etoys, MessageTally, ProcessBrowser, ImageSegments, etc.
> > loaded because I wouldn't know to update them to work correctly with the
> > new closure compiler.
> Which implies to me that a lot of stuff was poorly written to
> improperly depend on things it shouldn't. We are attempting to improve
> that, in between writing emails.

And more importantly - you (Anthony that is) didn't have all dependent
code in the image either! You only had the code that had been let into
the image. All code outside of the image has been rotting like hell.
Very important thing to realize.

> > 
> > I do agree we need modules in the image to better structure our code,
> > but the modules should all be in the same image so we can see all
> > dependents (to confidently make changes).
> Load them all and they will all be there.
> 
> [snip]
> > 1. Keep a single full image.
> As has been said quite a number of times recently there _will_ be a full
> image. It's just that there won't _only_ be a full image.
> 
> A distributed image than loads what it needs when it needs it is a
> lovely idea (and one I was proposing to Esprit committees over ten years
> ago for research funding) but requires reliable, secure, fast, pervasive
> connectivity. The world is certainly moving towards that capability but
> it isn't there yet and it doesn't help anywhere near all use cases so we
> cannot have a design that only works that way.

The new SM will have a proper package cache and since SM is a
centralized system we know *exactly* all available packages. This means
we will be able to deliver a fat zip containing a small kernel image and
a complete local SM. From that you can build a Gargantua image with
everything that doesn't simply conflict when installed.

But you could also easily build an index database over all references,
senders, implementors.

regards, Göran