My personal feelings, when i first implemented a HydraChannels and
tried to play with them, was is how little it is, and yet very
powerful :)
- a setup code is very little
- a data handling code is just before your eyes.

For instance a #doit channel implementation consists from few lines of code:

(HydraChannel listen: #doIt onReceive: [:data |
			[ Compiler evaluate:  data asString notifying: nil logged: true ] fork
		]) resumeAtStartup: true

.. once you execute this code, your image now listening #doit channel.
And by having doits, you can do virtually anything with it.

With channels, you don't need to care about many issues, which are
existing with non-reliable communications, like: out-of-order packets
arrival, packet slicing, data loss, and many other things which you
should care when using sockets, like resolving, buffering e.t.c..

I wasn't expected that HydraVM hides a great potential for playing
with images (there was no real intents to make it). Since you don't
need to care, if your image is having UI, and all what you need is to
keep it listening a #doit channel, with which you can fix virtually
anything, if something goes wrong.
During my experiments i lost one of my test images (UI stops
responding), but when loaded as secondary image, i was still able to
send doits to it, thus having a chance to restore things back to
normal :)

Andreas is right, a next logical step would be to make some tools with
which you can explore image contents and debug code in it.

But before going deep, i would like to get some feedback on channels
implementation.
There is some very interesting alternatives, which should be considered.

Currently a send mechanism makes following:
- allocate memory needed for buffer
- copy bytes from given bytearray into allocated buffer
- create a 'send' event, and finally put it into receiver's event queue.

On receiver's side:
- dequeue event
- find a corresponding channel
- if channel is found, put event into channel's queue , if channel's
input queue is full, ignore event
- if channel not found, ignore event
- by ignoring, its simply deallocates memory of buffer

When ST finally gets data from channel:
- dequeue packet from channel receiving queue
- copy buffer bytes in newly allocated bytearray
- deallocate packet buffer.

---
Alternatives:
- preallocated send queue with fixed packet length.
 This will eliminate the need in allocating/deallocating memory for
packets, making system work a bit faster.

- adding some feedback mechanism, when incoming packet can't be
delivered (when channel input queue is full, or simply there is no
channel with given credentials).
I'm not sure, if this is really needed to be implemented by VM. An
efficient error/feedback mechanisms can be implemented very easily at
language side.

- for an ultra fast communication, put packets directly into channel's
queue, bypassing interpreter event queue. This will require some
thought , how to implement it without endangering VM stability.
In this case, a packets can be handled right after few processor
cycles passed when channel received packet. You simply can't have such
speed when using sockets :)


-- 
Best regards,
Igor Stasenko AKA sig.