HydraTools and minimal images
Igor Stasenko
siguctua at gmail.com
Thu Feb 14 10:30:12 UTC 2008
On 14/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Thu, 14 Feb 2008 02:20:02 +0100, Igor Stasenko wrote:
>
> > Updated a HydraVM dev notes.
> > Some words about legacy plugins and added HydraStream into wish list :)
>
> > http://squeakvm.org/~sig/hydravm/devnotes.html
>
>
> You might want to add HydraSMS to the wish list (Hydra Synchronous Message
> Send, just claiming the name for now :)
>
> I will attempt a port of my NetworkContext project to HydraSMS, of course
> after your project supervisor has approved the test cases we discussed
> earlier :)
>
> The main purpose of HydraSMS is to provide a simple, lightweight, easy
> usable [etc, etc] synchronous mechanism for exchanging messages between
> two endpoints of a network (between two Hydra .images). This can be used
> for controlling any form of asynchronous computation in multiple Hydra
> .images, for example without always having to compile #doit's (imagine
> 10'000 requests per minute polluting the .changes file ;-)
>
Hehe, i assuming you realize that #doit's channel is just a system
default channel, which should be available for anyone. You can always
create own, pervasive channels, handling a data in pervasive manner
without polluting any files :)
It's as easy as doing:
myOtherImage := HydraVM loadAndStartNewImage: 'myOther.image'.
HydraVM doIt: 'HydraChannel listen: #myPervasiveChannel onReceive: [:data |
<place your code here> ]' on: myOtherImage
now your just loaded image listening a #myPervasiveChannel
and you free to send anything to it :)
> The unit of transfer is Smalltalk's block (i.e. what is transferred is
> control, back and forth). All that is needed is to compile the very same
> method in both Hydra .images once before using it. From a security point
> of view, you are supposed to trust the very same method in both .images ;-)
>
> Example with bells and whistles, except exception handling:
>
> mySMSexample
> | sms tmp |
> sms := HydraSMS with: #myChannel at: 2.
> "I'm now running in the other image, in which I do, "
> sms atHomeDo:
> ["this block is performed back in the initiating .image"
> sms nextStringPut: 'a parameter'; atWorkDo:
> ["and this nested block is performed in the other .image"
> tmp := sms nextString "get the parameter"
> ]
> ]
> "both sides always return self"
>
> HydraSMS (aka NetworkContext) provides protocol for #nextString* and I
> think about supporting SmartRefStream as well.
>
ermmrmrm.. can't quite understand what given example suppose to do.
suppose you having a method in HydraSMS class
foo: aString
and now, if you wish that by invoking a #foo: in your 'home' image,
string should be passed to 'work' image, you write there:
mychannel send: aString.
At other side, when you received a string, it may be collected
somewhere, so on next call to #nextString, it will return the first
available string in FIFO manner.
I don't see a reason in transferring a blocks (compiled bytecode),
since you stating, that both images containing very same code (and if
not, you can always perform a pervasive doit to make it appear :).
>
> /Klaus
>
--
Best regards,
Igor Stasenko AKA sig.
More information about the Squeak-dev
mailing list
|