Modular Squeak, Server Environments

ajh18 at cornell.edu ajh18 at cornell.edu
Mon Feb 26 19:29:42 UTC 2001


Hello Squeakers,
Below are some suggested enhancements for a modular Squeak universe.

Make it so you can access published objects in other images (or super
swikis) via variables in your own Smalltalk environment.  Globals such
as BobsSuperSwiki, UIUCArchive, etc, could be included in your image
that would trigger a connection with a server image upon access.  For
example, to download and enter the FunWithMorphic project from
BobsSuperSwiki you could execute "BobsSuperSwiki FunWithMorphic enter". 
Com, Org, Edu, Fr, Uk, etc, would also be globals in your image.  Doing
"Org Squeak" would access the image listening at squeak.org:8020 and
return a proxy to its "Org Squeak" environment.  The same environment
path is used in the remote image, so originals and downloaded copies can
live in the same environment, and variable references to it and from it
can remain the same.

When a published object is downloaded, the variable that refered to its
remote proxy will now point to the dowloaded copy.  To make this work, a
global like "BobsSuperSwiki" would contain a special object called a
ServerEnvironment which will first lookup a variable in its local
dictionary and the local dictionaries of it parent environments, and if
not found, connect to its remote server and ask it for the variable. 
When a variable is downloaded it gets added to the local dictionary. 
"Org" and "Org Squeak" would also be ServerEnvironments.

When an object is uploaded/downloaded its entire export segment is
copied.  For adequate decoupling, the leaf objects of export segments
are byteArrays, wordArrays, SmallIntegers, and/or DiskProxies. 
DiskProxies are just references to environmental objects (objects that
are part of the user's system and should be referenced via the Smaltalk
environment).  Adding servers to the Smalltalk environment allows
published objects to reference each other indirectly through environment
variables.

What if a downloaded segment references a Smalltalk variable (like
AnthonysSuperSwiki) that does not exist in the client image? 
Environment references (DiskProxies) should contain a default value to
install in case the environment variable does not exist.  For
AnthonysSuperSwiki, the default value would be a ServerEnvironment
containing the network address of the AnthonysSuperSwiki server.

Constraints can be added to environment references (DiskProxies) that
make sure the referencing object is compatible with the environment
value and converted if necessary.  This is a generalization of what
SmartRefStream does with classes and the instances that refer to them.

Instead of variables like BobsSuperSwiki and AnthonysSuperSwiki being
added to the top Smalltalk environment, they should be added to a
sub-environment like Swikis.  I like keeping the top level for general
categories like Tools, Network, VMConstruction, etc., like when the image
is partitioned into Environments by system category.  These system
environments could be ServerEnvironments that pointed to Squeak code
servers.  This way you can download only the classes you need, or want
to override.

What do you guys think?  We need a consensus to make this work.

Thanks,
Anthony





More information about the Squeak-dev mailing list