Two things -

Model vs Mechanism

You say memory foot print I say who cares. 256MB is quite achievable for
a PDAs nowadays, so I'm not sure it's a big benefit. OTOH, that's just
Mechanism. You mention switchable environments - now that's a Model
issue. 

One PIE paper shows a good role for layers as a model of programming
(layers as a programmers product - a unit of code modifications). Then
it mixes it up with all the decisions they make due to machine
limitations - needing to switch between states rather than forking a
process, implementing the aspects as a low level mechanism (affecting
object storage).

Who cares? after all these years, I don't care a bit for all their
mechanism, but I am very sorry we still don't have a model as developed
as they did for programming.

For the same reason, if you tell me you want to make images able to
share read only pages of memory in which class objects live, sort of
Smalltalk DLLs, similar in some ways to SmallScript, I'd think it's also
technically an interesting idea, but I'd still ask what's the model.
Saving memory is not the issue here.

What our models are is the big question, and how do we start modifying
the way we work, to realize them as quickly as possible. 

Mechanism vs Mechanism

The more you talk about switchable layers, the more, I think why not get
the same capabilities from richly communicating separate images, reusing
the OS/separate VM's protection?

About projects - the problem with projects precisely exemplifies the
issues at stake. First, you need to have projects be dependent on a
specific configuration, and be able to download that automatically
(using SM). We're mostly agreed there. Second, you need to be able to
activate it, while isolating it properly from your current image. So
yes, right now, I know I'd load more projects if they were simply run in
a separate, new process.

In fact, when I start to think about it, a complete alternate Squeak
universe unfolds. Imagine a GUI image, that has all the GUI tools you
want, but doesn't generally run the models. The models run on one or
more headless images. I have a mail image, and I have a completely
separate development image, but their GUIs run on the same image. Most
of the browsers and workspaces simply happen to be connected to the
development machine. Communications between the image are kept mostly
asynchronous, and on simple, standard protocols, and completely for
free, you get a Squeak that runs very well on SMP machines. Or
distributed across a network.

And yet at any time, you can connect a browser and an object explorer to
a specific image, and KNOW, that in front of you within this address
space, is something as simple as a completely self consistent Smalltalk,
separate from the rest of the world, except for the above
communications.

Daniel

Anthony Hannan <ajh18 at cornell.edu> wrote:
> Hi Daniel,
> 
> If you look at environments/layers as configurations and classes as
> the loadable units, then a configuration specifies which versions of
> which classes to load.  It may do this by including (inheriting) other
> configurations then adding/overriding classes itself.  If the user
> switches configurations it is very reasonable to expect things like the
> world menu to change.  However, if he stays in his own personal
> configuration and just changes which other configurations it inherits,
> then if he inherits two configurations that have two different versions
> of the world menu then an exception will be raised because it is
> ambiguous.  So conflicts will be raised and must be resolved.
> 
> Ideally there would only be one version of each class, and configurations
> would just specify which ones to load.  But allowing different versions is
> needed, because full collaboration is impossible.  New class versions can
> be submitted as replacements for originals, and the best way to do that is
> to put the new version in its own configuration so others can inherit
> from it and test it.  Then when it is tested and accepted it can be
> promoted to the original configuration.
> 
> Remember, I am still a proponent of class extensions that are actually
> separate behaviors/classes in a multiple inheritance hierarchy.  This
> way new versions of classes are just changes and not additions of new
> behavior.  With class extensions as separate classes, we only need
> configurations and classes, eliminating the need for a third intermediary
> concept (packages).
> 
> As for multiple images, even if memory is cheap we don't want to waste
> it, so PDA users can load and run as many applications simultaneously
> as possible.  So I really think we should strive for one "operating
> system" image.  And as for a safer non-crashing image I think layers/environments/configurations would actually help this.  When a
> critical error happens, the user can be moved to a safe configuration
> automatically.  He would still be able to inspect the damaged
> configuration because its still in the image, its just no longer running.
> See
> http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Kansas/Kansas.html
> for an example of this done in Self.
> 
> Finally, without different configurations allowed in the same image how
> do you expect to handle Squeak Projects, and switching between them
> easily?  The current mechanism is very fragile and needs to be fixed. 
> Today, projects can only be loaded in images that are sufficiently
> similar to the image it was created in.  If certain functionality is
> missing or changed the project will break.  It has no way of determining
> or loading the base image it depends on.  It only know local changes it
> made inside its project.
> 
> Cheers,
> Anthony
> 
> 
> Daniel Vainsencher <danielv at netvision.net.il> wrote:
> > Ah here I definitely disagree - I think this is a huge landmine.
> > 
> > Whether people come to use a layered system for it's real benefits or
> > not, I think it would be a disaster if people use it to ignore trivial
> > incompatibilities between packages.
> > 
> > Remember that one of the great benefits of free software development is
> > the testing. It's a critical part of the magic. For a modular
> > environment, as Squeak is already headed to be since the day SqueakMap
> > is online, integration testing is a large part of the issue. 
> > 
> > Where two packages need significantly different functions, they should
> > be using two separate, mutually neutral actual mechanisms. Where two
> > packages need slightly different versions of the same thing, this needs
> > to be visible, slightly painful for all involved, until it is resolved. 
> > 
> > I'll give you a concrete example - if each package, as part of it's
> > layer, should bring in it's own version of the TWM>>openMenu, everything
> > would "work", and the user might go mad before understanding why it
> > keeps changing on him. The solution is to find these areas of conflict,
> > however small, and redesign them for cooperation. Not to apply a
> > one-size-fits-all plaster that allows all packages to ignore one
> > another.
> > 
> > The real solution is for package maintainers to avoid patching other
> > packages, in your package, instead submitting patches to the upstream
> > packages maintainer. And concurrently, to give the user tools to notice
> > and control when this is happening.
> > 
> > Memory is cheap, and cheaper every day.
> > 
> > For an OS, it gets unfixably stuck too often. We have issues to solve here 
> > much before we need layers.