Distributed Squeak

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Mon Apr 14 21:18:39 UTC 2003

Hi again!

Anthony Hannan <ajh18 at cornell.edu> wrote:
> Michael van der Gulik <mikevdg at hetnet.nl> wrote:
> > If anybody knows of any related existing systems or technology not 
> > mentioned on dpon.sourceforge.net, I'd like to know.
> Don't forget to check out the E language (erights.org), for
> distribution, capability security, and concurrency ideas.
> As Goran said, check out Magma.  A distributed image is similar to an
> object database (a la Magma).  The main difference is that a distributed
> image allows distributed computation as well.  With an object database,
> all objects have to move to the client and all computation has to be
> done on the client.  But there should be some common functionality, so I
> would definitely look at it and contact Chris Muller.

Well, you can combine a "remote message" framework with it to get that
kind of distributed messaging too. GemStone has mechanisms like tat for
example. Well, at least GemStone/S - the GemStone/J was dumbed down in
that department, they just fell back on RMI which doesn't preserve any
object identities.

And... don't forget that you *have* distributed computation with an
OODB! Obviously the objects must move into a running Smalltalk in order
to be processed (instead of being on the disk). And where that running
Smalltalk is placed in the network is irrelevant.

Let me give an example. There is nothing stopping you from doing this
today in Magma (AFAIK):

1. Set up a Magma server. It doesn't execute any behaviour - it just
serves "client" Magma processes.

2. On the same machine as the server - start a Squeak Magma "client"
that connects to the local server. In this Squeak process you can
manipulate the objects "on the server".

3. Start another Magma client on another machine. Let it connect to the
Magma server. Let it communicate through the model - for example, create
an OrderedCollection in Magma. Let the client add a Job instance and
commit that. The server Squeak process can then discover these, process
the jobs and remove them from the queue. So the client is using Magma to
communicate with the server.

Anyway, I object to the statement above regarding the "..all objects
have to move to the client...". :-) I would rather say "...objects must
move into a Squeak image to be able to behave." And that is pretty
obvious! :-)

> Also, check out squeak image segments, particularly primitive image
> segments that the class ImageSegment uses.  The class uses DataStreams

Right, I have been using those too as a fast and solid way to persist
object models and load them back into the image. Works like a charm, if
you search the archives you should find a "howto" I posted on that

regards, Göran

More information about the Squeak-dev mailing list