A Proposal for Project Layers

Daniel Vainsencher danielv at netvision.net.il
Fri Nov 19 19:04:35 UTC 1999


Lots of this-is-how-it-should-be-bla-bla. New(?) proposed requirements for 
ProL below ***s.

First of all, I think the the Project Layers work is very interesting.
I love two consequences of it - 
1. Anyone can create demos/explanations/tutorials and distribute them in a 
form that's really accessible to end users (which fileins are not...).
2. Anyone can create generic packages in such a form.

To me the first is important because of the large potential number of added 
creators/markets of content.
The second is important because of the great number of different applications 
for it. These include a modification of the "Squeak Universe" in which we 
operate.

I think there's a lots of noise happening to the effect that people want 
easier access to other people code, without waiting for it to hit the top of 
SCs priority queue.

There are several projects happening in the squeak world that would benefit 
from having the sort of distribution prowess that SC enjoys. (Stephan's 
images, MathMorphs, Craig's correspondents?, the raw bug-fix stream (if you're 
adventurous)...).

I propose the image hold a (growable) list of sites (SC, minnow, Fred's Squeak 
Warez...). Each site will hold a list of update streams and the contents for 
each. Some of the sites may allow posting of fixes by anyone (restricted 
versions might also be useful).

A simple application will allow the user to see how many and what updates are 
available for each stream he has registered.

Note that the update numbering is per list. From a short look at the code for 
updates, not much separates the update streams from being multiple, but the 
numbering is one of those things.

***
Some needs I wish to raise -
1. (Not to the point) I want to have an arbitrary number of update stream 
coming into my Squeak. (but suggests - )
2. I can monitor/control which projects each stream may modify. (I want to 
accept all modifications from SC, all modifications from the MorphicWrappers 
stream, but only to the MW project, so forth).
3. I want to have a Preferences project which is generally not updated (maybe 
only added to) by any streams. Sick of reconfiguring things.
4. Same should go for Celeste. This means the image should be able to find 
local, persistent repositories and connect to them easily.
5. When the project you're in chokes, allow a key press to send you to another 
project, with a debugger tuned to the world you left, so that the debugger 
works in it own plain vanilla project, but simulates life in another. This is 
another line of defense against screwing up a more-basic-than-you-thought 
method.

BTW, it seems that distributing images will become even less important (update 
streams have made that needed mostly for PWMs). Download a minimal image + 
sources (that can be *very* stable) and you're mostly set. This leaves only 
the VM both platform specific and volatile. And with plugin primitives, we 
might cool the VM down too. Thats pretty cool.

Daniel





More information about the Squeak-dev mailing list