On Thu, 14 Feb 2008 11:30:12 +0100, Igor Stasenko wrote:

> On 14/02/2008, Klaus D. Witzel 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.

Sure, you wrote that some time ago.

> 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 :)

Nobody said that this wouldn't be possible; I don't see this compares to  
HydraSMS. BTW you forgot to write the things in the above which make your  
"counter" example synchronous ;-)

>>  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.

Demonstrate the synchronous transfer of c-o-n-t-r-o-l and a snippet on  
how/when/where to pass an argument. Have this solved once so that the  
zillions of asynchronous computational tasks (I mean, future projects  
which want to benefit from Hydra's multi-processor capabilities) can be  
c-o-n-t-r-o-l-l-e-d predictable and reliable.

> suppose you having a method in HydraSMS class
>
> foo: aString
>
> and now, if you wish that by invoking a #foo: in your 'home' image,

No, I didn't attempt to have an asynchronous string sent to another  
.image, do you pretend to not understand what synchronous is about :)

> string should be passed to 'work' image, you write there:
> mychannel send: aString.

But why the heck use that low level stuff, why not abstract away each and  
everything?

HydraSMS can do the same work over Sockets and (possibly, we have as yet  
not gone that far) over channels, without one bit of change. Not that is  
it therefore "better"; it is using the low level constructs you always  
give in your "counter" example, no doubt.

But whenever *you* write "myChannel send: aString" like in the above, you  
are obliged to also write all the checks before+after, that everything is  
still O.K. Otherwise that's not comparable to what HydraSMS is about.

Don't misunderstand; it's O.K. that "myChannel send: aString" exists, many  
(if not all) things will be built on top of it ;-)

> 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.

There's no doubt about the possibility of sending and receiving things  
through Hydra's channel.

> I don't see a reason in transferring a blocks (compiled bytecode),

Transfer of c-o-n-t-r-o-l is not the same as transfering compiled  
bytecode. HydraSMS doesn't transfer the compiled method, I wrote that  
earlier.

> since you stating, that both images containing very same code

Sure.

> (and if
> not, you can always perform a pervasive doit to make it appear :).

I think the divergence that you attempt here is because I try to abstract  
the nitty gritty details away?

Please: let's not waste our time discussing your asynchronous arguments  
v.s. my synchronous attempt with HydraSMS.

>>
>>  /Klaus
>>
>