Getting Ready

[Dan Ingalls]

Folks -

First of all, special thanks to those of you who took the time either to write a sort of position paper, or to fill out one of the summaries.  This really makes a difference.  It's exciting to embark on this project with such a knowledgeable crew.

That said, I want to get the entries for Naiads and Islands filled out, and I'm hoping to get something on Universes as well, before we really blast off.  Craig, Andreas, and Lex, if you are listening, would you be willing to take a crack at these?  Anyone else?  See the New Modules page,

	http://minnow.cc.gatech.edu/squeak/5608


Meantime, here are some appetizers to get you ready for the main course...

Think about a little PDA with ROM and RAM.  Suppose we blew the squeak image in to the ROM.  Could we run with it in ROM?  When we wanted to save, could we only save the differences from the ROM?  If we started it up again, and made some more changes, could we just save those changes? What do these incremental snapshots suggest about modules?

Consider Packages and Projects.  We might well open a new project, build a package, and store it as a project.  Or as a package.  Compare and contrast these two modes of use, in particular noting how they might use the same underlying unit of modularity, and further noting in what other aspects they differ.

Imagine a change to the VM which would allow message lookup to be intercepted.  If we are writing some application and want to add a few methods to class String, then we put them in a StringExtensions class in our package (sometimes called a virtual class).  A little table in the VM notes this and, when a message is looked up in class String, it is first looked up in StringExtensions.  Things may go a little bit slowly on the first lookup but then, of course, the method goes into the cache and there is no performance penalty.  But look -- we have not modified class String at all.  Time to uninstall?  Zero.

Now imagine that the VM can have multiple method caches, one per, um, per process?  per module?  Think about it.  And when you have figured it out, note that this system could run simultaneous multiple projects with conflicting changes to root classes with no performance degradation.

Think about an image nicely partitioned into lots of little segments corresponding to different modules.  Might it make sense to garbage collect them separately?  And what about other aspects of storage management?  Supposing we are concerned about security, and someone attacks the system by consuming more and more storage.  How do we catch that?  How do we make sure that it only affects the requestor, and not the rest of the system?

More later

	- Dan