A message for data waiting at a socket?

[Doug Lerner]

On 1/3/04 2:49 PM, "Phil Davis" <davis.phil at comcast.net> wrote:

> 
>> -----Original Message-----
>> From: use-revolution-bounces at lists.runrev.com
>> [mailto:use-revolution-bounces at lists.runrev.com]On Behalf Of Doug Lerner
>> Sent: Friday, January 02, 2004 7:41 PM
>> To: How to use Revolution
>> Subject: Re: A message for data waiting at a socket?
>> 
> --- snip ---
>> 
>> What would be nicer though is if data were pushed from the other side (the
>> server I am connected to) to the socket that that would send a
>> message to a
>> handler. That seems more dynamic and efficient and "in the spirit" of a
>> message-driven system. My app could then respond whenever data arrives.
>> 
> 
> Nice idea, Doug... but for the message-driven model to apply, the two stacks
> (client and server) must share the same Rev session. Since they're
> [presumably] on different machines, that can't happen.

Wouldn't the client just need to be aware of "something changed" on its own
side?

> 
> I suppose you could virtually join the two environments with a 'socket
> reader/message dispatcher' stack running on each machine. Its job would be
> to:
> - receive socket data from 'the other side', translate it to Rev messages
> and send them within its local Rev environment.

That's sort of what I'm doing now. But rather than sending back entire Rev
messages, I'm sending back command/data pairs and then parsing and
processing them on the Rev side.

> - receive local Rev messages, translate them to socket data and send the
> data to the other environment.

For that, I am turning them into an xml string, sending the string back as a
parameter to the other environment which has the ability to take the string,
convert it to a server-side object and then just pluck the command/data
pairs out of that for processing. Then it sends results back to Rev.

So immediately after a write I am invoking a read to get the results and
that works fine.

But sometimes the server side wants to push data through even though I
haven't just written anything to it. That is what I am trying to handle.

Right now I am dealing with that by sending a message to a refresh handler
every five seconds there has been no other interaction. I figured a true
handler response to a push from the other end would be more "dynamic"
though.

doug