On 12 août 2010, at 15:58, Ralph Boland wrote:
>
> Would RemoteSmalltalk be helpful in (be a foundation for) creating
> such a utility?
>
Yes. But, we need an appropriate set of tools. We (Douai's team) developed a
few tools a while ago as part of the UbiquiTalk project. We had a
remote-workspace working quite fine. We started an experiment with a remote
browser based on omni-browser. But, it was a failure. Omnibrowser does a lot of
computations resulting into a lot of network traffic. The browser was to slow
to be usable. We started introducing caches, but there were too many things to
cache so we gave up.
Noury
> Regards,
>
> Ralph Boland
>
>
> 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.
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
