I would like to second Patrick's desire and his lamentation that 
     communication and coordination is a bitch.
     
     In fact, I would like to expand that desire to include the necessary 
     capability to run lots of Squeak images on a multitude of robots of 
     varying capabilities and with varying levels of autonomy but acting 
     cooperatively. I want to hook up a radio device to my PC and 
     initialize, communicate with, and control all these robots with as 
     little pain as possible. I would like to be able to communicate to 
     them in both synchronous and asynchronous modes. I would also like to 
     be able to debug any of the images from my PC.
     
     I see some of this capability in my current work with semiconductor 
     processing equipment software. Our equipment runs distributed software 
     build on top of ControlWORKS which is a VisualWORKS framework for such 
     equipment. The controlling image runs on NT Workstation and 
     communicates to images running on VxWorks embedded systems which 
     eventually control the actuators for the hardware. Debugging of the 
     embedded images is done on the NT Workstation.
     
     I lean toward the simple message passing approach. I want to be able 
     to ask an image via messages what it can do and how I should tell it 
     to do such things. I also want to be able to ask it if it can do some 
     particular thing I already have in mind. Of course, I want to be able 
     to do this programmatically.
     
     Enough dreaming. Back to work.
     
     Jerome E. Garcia
     
     Jerome.Garcia at wj.com
     jegarcia at adventurousmind.com


______________________________ Reply Separator _________________________________
Subject: Distributed and concurrent Squeak
Author:  Patrick Logan <patrickl at servio.gemstone.com> at INTERNET
Date:    10/13/98 2:35 PM


     
    I would like to create an application which runs seamlessly across 
    multiple machines and platforms, but it's too hard because the 
    communication and coordination is a bitch.
     
    Possible solution:
            Expand the "image" concept to encompass an 
            entire "world".
     
    Not having access to a Sun platform I've never run Self, but the 
    descriptions I've read make it sound like Self did something like 
    this, at least for the development "half" (the other half being 
    the deployment "half").
     
    Basically I want collaboration with little pain and lots of gain.
     
Another approach is the simple message passing approach. This would be 
interesting to consider, given Alan Key's recent email to this list 
about "messages" vis-a-vis "objects".
     
Consider the programming language named Erlang from Ericsson. It is a 
concurrent and distributed language with no shared memory. All 
communication is by sending high-level messages. Receivers can pattern 
match on messages with time outs, etc. What Erlang calls "processes" 
can be linked to each other for high level process control and 
reliability.
     
There are several production-quality communications programs built 
with hundreds of thousands of lines of Erlang code, so it seems to 
have some practicality, which may meet the "lots of gain" 
requirement. The simplicity of it seems to meet the "little pain" 
requirement.
     
Another approach is the Linda model which provides more of a "shared 
name space". The Erlang approach provides a name space of processes 
where Linda provides a name space of messages. Gemstone provides a 
model of the "worldwide multi-user image" but that is a much more 
complicated approach for the implementor.
     
-- 
Patrick Logan                 mailto:patrickl at gemstone.com 
Voice 503-533-3365            Fax   503-629-8556
Gemstone Systems, Inc         http://www.gemstone.com
     
"I am not a Church numeral; I am a free variable!"