Juan Vuletich wrote:
> My own Squeak direction is described in 
> http://www.jvuletich.org/Cuis/Index.html . As it seems to be 
> incompatible with that of many in the community, it requires a fork.
> 
> Aside from that, I fully support your direction, and I'll try to keep 
> helping. Of course, I'd be delighted if at least some of my objectives 
> were adopted for Squeak too.

While it is good to avoid forking as much as possible, I always like to
remind people that Squeak 3.8 was a merge of four forks (squeak.org 3.7,
Squeakland, SmallLand and OpenCroquet) and that merges might also happen
in the future. My own vision, described below, requires a radical
rewrite of ObjectMemory and a significant patch of message sending in
Interpreter. So this will probably require a fork as well (we shall see
- I had hoped to be able to work on this starting in August, but now
next January seems more likely).

I would like for there to be a single, world-wide image for Squeak. This
would be split up into many relatively small, immutable files for
storage. A given machine probably wouldn't have access to the whole set
of files at any one time. This image would support multiple simultaneous
viewpoints such that if you have a pointer to an object and I have a
pointer to the same object we might get different results when sending
the exact same message. The viewpoints are managed mostly manually with
a reasonable visual representation.

Each node only loads into RAM as much of the global image as it needs to
run its current code. Several nodes might collaborate by loading
different parts of the image and sending messages to each other.
Alternatively, several nodes might load the same parts of the image and
keep in sync with the TeaTime scheme. Machines with 16 thousand
SiliconSqueak cores are in the early planning stage, which gives you an
idea of how far I think we can scale this.

At the other extreme, a headless application running on a single core
with only the barest parts of the image that it needs to support it
should fit easily in just 128KB of memory. Other applications might have
fancy multimedia features and I would like the option to have as much of
this in Squeak so that bare hardware is a practical platform, even as
Squeak makes better and better use of native features in other OSes. I
would like SqueakNOS to be safer and more robust than current OSes.

-- Jecel