hi all

I have been discussing with marcus/alex and also thinking about that 
after my remarks on andreas remarks related to
changes, interfaces/ cleaning vs changes. So to avoid get frustration 
from all the parts and to state clearly what is our
plan for 3.9 we would like you to read the following and let us know. 
Depending on the reactions, we (the guys from berne) may decide to 
produce our own stream, because we must work too ;). But we understand 
that other people cannot deal with a system changing. But in that case 
we should draw the consequences.

Our part that we will work on for 3.9 is to get the system improved 
from a developers point of view. We
think that having a good foundation is important for everybody.

The overall idea is to slowly improve one aspect of Squeak: The idea to 
have a System to build the next
System with.

This has lots of consquences, one is that you want the system to be in 
a shape that e.g., students that are not yet
complete Squeak experts can start to do experiments with it on a quite 
deep level, e.g., change the compiler or
add a feature to the Browser.  Another aspect is to have a System for 
research. The Traits project has been hugely
successful, but it has shown that Squeak does have real problems if you 
use it for stuff like that. If Squeak is supposed
to be the system of choice for research like this, we need to fix those 
problems, we need to make sure that the
lessons learned from those projects get fed back into the system. (One 
example is the change-notification that was added to 3.7, it is a 
direct result of the Traits project)

All this does not mean that 3.9 will only be about that stuff: We 
surely want to see e.g. the work of Diego beeing
included, also any changes that other people would need are welcome.

For our perspective here what we would like to have: we put in (p) the 
code that  will be in external packages,
which likely will be "full".

	- services
	- new preferences pane
	- OB (p?) + browseUnit new version
	- MC in the base image
	- rbengine (p)
	- shout (p)
	- SqueakMap II (yes we want it)
	- eCompletion or another package
	- keybinding
	- traits
	- new compiler framework of anthony adapted by marcus to produce
	not full block. Note that for Etoy the old compiler will still be in 
the image so from that point of view
	it should not have an impact.
	- refactoring of systemDictionary. (see below this point)

We are sure that we forgot something but this is what we have on top of 
my head.

Now for systemDictionary here is the situation and here is where we 
would like to be after 3.9

In the past we created SmalltalkImage out of SystemDictionary in the 
hope to have SystemDictionary be a nice
and simple namespace class. Lot of stuff has been put in coherent 
places (SystemNavigation, SpaceTally, Changeset....)
But this will not work since people get used to add stuff there and 
Smalltalk is a cool name.
So the new proposal is the following one and is partly implemented. 
Note however that it will require
from us a lot of work so if you are against it please say it and we 
will only do it for us.

from a user point of view we want to have:
	only one class: SmalltalkImage/SystDict for all the image related 
services
	(VM pluggins, ....) but the namespace behavior will be delegated to 
Namespace.

        All the previous code referencing Smalltalk will work but with 
deprecation for the namespace interface.

 From the language programmer point of view:
	there will be a namespace that can be used for experimentation
	this class will replace the environment class of dan that is now 
obsolete

We plan to proceed that way:
	- create a class namespace with a new interface (done)
	- delegate from systemDictionary to this new class (done but not 
published)
	- deprecate all the namespace method of systemDictionary (but we 
likely want to keep them for some time)
	- fix all the in image senders of Smalltalk as a namespace to use the 
new class (using self environment for example).
	(partly done over the previous years)
	- merge back SmalltalkImage into SystemDictionary: the idea here is to 
not have SystemDict as a subclass of Dictionary
	- have Smalltalk pointing to an instance of this new entity, so that 
everybody is happy.



Stef and Marcus