Which ultimately depends on sockets. Hopefully the next pass will support OpenSSL and be adaptable to things like IrDA (by having hooks sufficient to support anything that makes itself look like a socket), and make either robust use of asynchronous operations or OS threads to the point that non-responsive peers or DNS servers never lock the entire image, just the calling process. ConnectionQueue polls for connections - there needs to be either another semaphore, or another job for one that exists, allowing a process to wait until a client connects rather than looping and adding time delays :( Andreas' SSL plugin might be a good starting point or perhaps one part of a good solution?? Testing needs to be brutal, including viciously timed loss of power to network infrastructure. I am not sure if I can do that at work anymore, but I certainly can build an intranet. In fact, I have a really nice "old" machine that I rescued from the gas chamber, and an embedded computer (expected soon) that is part of a beta program and needs to be abused in various creative ways. Between them, I should be able to set up a very nice testing ground for network error handling. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, August 11, 2010 4:26 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Inter-image communication rst? RemoteSmalltalk?

How would I, from one image, tell another image to execute something?

I searched Google and the Squeak and Pharo lists for: - "[Pharo|Squeak] inter-image communication" - "[Pharo|Squeak] script"

The results included various references to old projects that I never hear mentioned now, and instructions on how to run code (via a .st as an argument to the vm command line) when launching an image.

Thanks. Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2320723.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Does it work over a LAN? Hilaire Le 11/08/2010 20:17, Sean P. DeNigris a écrit :

Stéphane Ducasse wrote:

...

rst? RemoteSmalltalk?

rst = RemoteSmalltalk = SO COOL!!!

I easily shared objects from a Pharo 1.1 image with 4 other local images - including a Squeak 4.1 image!

For a hoot:

1. In a Pharo 1.1 image with rST installed doit: "Transcript open. RSTSamples serverStartup"

2. In a Squeak 4.1 image with rST installed doit: "RSTBroker startOnPort: self clientPort logging: false.

remoteTranscript := ('Transcript@' , self serverBrokerID) asLocalObject. remoteTranscript show: 'everything is ok! (from client side)'; cr"

3. Pick up jaw after you see that the squeak image has sent a message to the Pharo image's Transcript, whose contents now appear as 'everything is ok! (from client side)'

n.b. According to the docs, in both images, doit: "RSTBroker stop"

How to load: I have no write access to rST, so the required packages can be loaded as follows: "Gofer new squeaksource: 'KomHttpServer'; package: 'DynamicBindings'; load.

Gofer new squeaksource: 'KomHttpServer'; package: 'KomServices'; load.

Gofer new squeaksource: 'SPDProjectUpdates'; package: 'rST'; load."

Thanks for the pointer!

1. This seriously frees me to play with objects in different forks and versions because I know I can beam the live objects to another image whenever I want, and not have them stranded. 2. This seems like it should be perfect for scripting an image, but what shared object would allow arbitrary code to be run on the server? I played with Workspace, but got lost down the delegation rabbit hole

Sean

p.s. I got it loading with minimal changes - just had to fix the underscore assignments, and break the dependency to an old version of KomServices.

Hi Sean, Thanks for sharing this. Is there a way you can put this online permanently, e.g., in a small blog post? I'm sure this is going to be of interest to other people... Cheers, Adrian On Aug 11, 2010, at 20:17 , Sean P. DeNigris wrote:

Stéphane Ducasse wrote:

...

rst? RemoteSmalltalk?

rst = RemoteSmalltalk = SO COOL!!!

I easily shared objects from a Pharo 1.1 image with 4 other local images - including a Squeak 4.1 image!

For a hoot:

1. In a Pharo 1.1 image with rST installed doit: "Transcript open. RSTSamples serverStartup"

2. In a Squeak 4.1 image with rST installed doit: "RSTBroker startOnPort: self clientPort logging: false.

remoteTranscript := ('Transcript@' , self serverBrokerID) asLocalObject. remoteTranscript show: 'everything is ok! (from client side)'; cr"

3. Pick up jaw after you see that the squeak image has sent a message to the Pharo image's Transcript, whose contents now appear as 'everything is ok! (from client side)'

n.b. According to the docs, in both images, doit: "RSTBroker stop"

How to load: I have no write access to rST, so the required packages can be loaded as follows: "Gofer new squeaksource: 'KomHttpServer'; package: 'DynamicBindings'; load.

Gofer new squeaksource: 'KomHttpServer'; package: 'KomServices'; load.

Gofer new squeaksource: 'SPDProjectUpdates'; package: 'rST'; load."

Thanks for the pointer!

1. This seriously frees me to play with objects in different forks and versions because I know I can beam the live objects to another image whenever I want, and not have them stranded. 2. This seems like it should be perfect for scripting an image, but what shared object would allow arbitrary code to be run on the server? I played with Workspace, but got lost down the delegation rabbit hole

Sean

p.s. I got it loading with minimal changes - just had to fix the underscore assignments, and break the dependency to an old version of KomServices. -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2321673.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 08/11/2010 10:26 AM, Stéphane Ducasse wrote:

rst?

RemoteSmalltalk?

Yes, and there are multiple other packages too. A few other things that might be interesting in "inter image communication": - D-Bus. Bert and the guys made a rather ambitious plugin for libdbus and stuff above it. This is not interesting for Squeak2Squeak, but definitely interesting for cross language stuff. - Message Queues. There are tons of these today, like RabbitMQ, ActiveMQ etc etc. And there is an AMQP protocol implementation on SS, and yesterday I released a first shot at a STOMP implementation too! These message queues implement publish/subscribe models etc so they are different beasts, but IMHO possible more interesting than "straight RPC". - If you go for a transport level that is "non Smalltalk", like say a message queue above, then Tirade (also on SS) could work as a fast way to "serialize messages" through such a transport. When I get STOMP finished I will make a simple demo of that. Also, writing a forking Socket server is really simple in Squeak. The Blackfoot package on SS can act as a really simple and documented example of such a server. Also, if you want to play around with character/byte-streams between Squeak Processes (in one image) then the SharedStreams package is neat - in fact, I think it should be included in the "standard library", and probably also replace SharedQueue. regards, Göran