On 13/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> Hi Igor,
>
> on Wed, 13 Feb 2008 09:35:09 +0100, you wrote:
>
> > 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.
>
> Yes, HydraChannels look easy and straight forward :)
>
> ...
> > And by having doits, you can do virtually anything with it.
> >
> ...
> > 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.
>
> I think that at the time being, debugger would be of higher priority than
> browser, since filing in source code from filedOut material is already
> solved by using #doit channel :)
>
> > But before going deep, i would like to get some feedback on channels
> > implementation.
>
> If I had a wish free then I'd say that Hydra's channels could provide the
> [a sensible part of] existing vocabulary of Socket (Socket's messages
> categories #open, #queries, #receiving, #sending and #waiting).
>

There is, a waiting (hidden from your eyes).
You can check the HydraReceivingChannel>>startListening: aBlock

VM signals a semaphore, when data arrives on channel, so a process
which is waiting on that semaphore is then awaken and can do anything
he needs to handle incoming packet.

Actually, you can omit using semaphore, and just pull data from
channel at any time you need.
The readData primitive works pretty straightforward: If there is data
waiting on channel, you'll receive a bytearray, if not - you just
receive a nil in response, indicating that channel input queue is
empty.
So, you can implement own listening scheme, which polls channel for
data periodically, and if there is no data received after supplied
timeout, evaluate a onTimeOut handler..


> This would make porting Socket-based applications easier and can leverage
> existing knowledge about Sockets.
>
> > There is some very interesting alternatives, which should be considered.
> ...
> > ---
> > Alternatives:
> ...
> > - 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).
>
> Considering a port one of my projects which currently is using Sockets,
> what I'm missing is something like #waitForDataFor:ifClosed:ifTimedOut:
>

A channels is unidirectional. You sending data and have no feedback.
It works in same way as UDP sockets.
But on top of UDP you can always build more sophisticated layers (as
bidirectional streams), where you can introduce behavior like
#waitForDataFor:ifClosed:ifTimedOut:.

> Is something like that possible with the Hydra channels primitives?

... and there is no need to make it at VM level. It can be easily done
at language level.

>
> > 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.
>
> It wouldn't need more/other error/feedback than what Socket provides
> today, IMHO.
>
> BTW: what's happening now if the second .image does no longer respond to
> the first .image, how can/does the other .image get known to this?

Again, there is no 'response' in any means. Channels just listening
for data. You can send data to channel, but you don't getting any
feedback about if it was delivered or handled.

To build a system with feedback all you need is to setup two channels
(one for each image) and create a feedback protocol, like, when
channel receives a message, it sends a message back, that he is
actually received it :)

As a small exercise of bidirectional communication, you can check
HydraPing class.

>
> /Klaus
>
>

-- 
Best regards,
Igor Stasenko AKA sig.