World: r3wp

i still need to figure out how to interface incoming data frames 
with the RSP engine

That's where my Cheyenne websockets attempts hit the fan. Not so 
much the RSP, buf from a tcp socket to http and back again.

SVN r45 : Web Sockets support


FEAT: experimental Web Sockets support added. (See %www/ws.html and 
%www/ws.rsp)
FIX: regression on bad HTTP request filtering. (Thanks to sqlab)
FIX: minor code clean-ups.

You'll need Chrome 4 to be able to use web sockets (don't know about 
other browsers).

Currently, your web socket URL must point to an existing RSP script 
(or a path that translates to a RSP file). The included %ws.rsp script 
is just a simple echo service.

Once connected, all the web socket traffic is directed to the starting 
RSP script, where you can implement your own application specific 
protocol and action dispatching while benefiting from the RSP webapps 
features (like the webapp filesystem structure with private/public 
folders).

Server-side 'connect and 'close sockets events are missing. Not sure 
how easy it will be to add them to the RSP application model. More 
generaly, the web sockets require a shift in the whole application 
model, the RSP engine is tuned to request/response model, not client/server. 
I'm not even sure that such server can be built in a efficient way 
with REBOL without multi-threading support (can't share port! values 
between processes).

Just think about how a minimalistic multi-user chat app could be 
built using web sockets. The application code needs to be able to 
access all the existing connected sockets to broadcast user posts, 
but these sockets are connected to the main process (UniServe) while 
the application code is run in worker processes...Having everything 
in one process would solve that but you can't run any scalable app 
with such model (beyong just passing messages between sockets). That's 
where mutlti-threading would have been useful...

We should push for R3 finishing task! datatype then, if you need 
threading :-)

Does this mean you can now  more easily write a web control panel?

And does it make it easier to use Cheyenne's mail server?

I downloaded Chrome 4, and when I access the ws.html, I get a chrome 
requester that says "Conn closed" before I  even get a chance to 
click on the "Send Message" button.

Anyone else tried this?

SVN r45 ?

is there a link?

code.google.com

yeah, just found it

Doc, I'm not sure RSP is the proper handler for websockets.  The 
earlier stuff i was working on used a forever loop. Isn't RSP more 
traditional stateless?

working fine here Graham

I'm not even sure that such server can be built in a efficient way 
with REBOL without multi-threading support (can't share port! values 
between processes).

This is where i hit the wall in the past.  (Look back in this group 
to Nov 8th and prior posts)
 

Isn't "just passing messages between sockets" enough? What else did 
you have in mind?
My thought would be a business layer managing sockets? no?


Anyway.. nice work.  I told you it would only take a couple of  hours 
for a guru  :)

Graham: you should check if your server is reachable on this URL 
: http://localhost/ws.rsp(it should if you're using the config file 
from SVN). 


Web Control Panel : yes, it's easier with web sockets than with COMET 
approach, but it's not a show stopper anyway.

Mail server : it could make it easier if you're using a client supporting 
web sockets.

Can i put a forever loop in RSP, and how would i push the buffer?

No you can't, it won't work (RSP engine use a request/response model), 
but even if you could, that would mean one process per client connection, 
definitely not scalable.

Strikes me as a new Uniserve service

My thought would be a business layer managing sockets?

 If you want a kind of bridging server (web sockets<=> Server <=> 
 TCP), there's already existing products doing that like http://www.kaazing.com/products/kaazing-websocket-gateway

Well, there's already existing web servers as well. .That's not the 
point.

This could be a Kaazing killer

(Watch that pop to the top of Google when searching 'Kaazing' :)

Needs to be in a forever loop somewhere. I'm guessing a service (or 
protocol.. can't remember which)
so that you can connect and to this.. 

forever [

do %somehandler.r

]

where somehandler.r could manage the connections? no?

so the "polling" aspect is moved from the client -> server.. to an 
internal script via multiple forevers 
or sumtin' like that ?

something like taskmaster?

I don't get your "forever loop" approach, UniServe uses an event 
loop.

I'm looking for some old experiments

but wouldn't it just be standard on-connected , on-received  protocol 
handlers anyway?

it requires some kind of null event at the end of each incoming message

install-service [

    	name: 'test
    	port-id: 3001
	stop-at: "^@"

(that's the standard Flash EOF)

on-received: func [data][ 
	theIP: client/remote-ip
	do %websockethandler.r	
]

If you're trying to ask if a gateway like Kazaaing can be built using 
UniServe, the answer is : sure and it will be scalable.

I think the hard part is done already.. dealing with ws://

(maybe wss:// might be a little trickier :)

It's exciting.. i'm sending javascript back to the browser via the 
websocket to be eval'd.. the browser just became a killer GUI

Important notice wrt web sockets : IIRC, all data sent on both sides 
have to be UTF-8 encoded. The current Cheyenne implementation doesn't 
enforce that encoding, so it's up to the developer to send the right 
data format.

This is apply to the so-called "text frames" which Cheyenne supports. 
The other kind of frames (binary frames) doesn't require such encoding 
(not supported by Cheyenne yet).

UTF-8 support is icing on the cake.

This is apply => This applies

Here's quick demo of pushing javascript back for eval

---------WS.html--------------


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Welcome!</title>
	

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js'</script>

<script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js'</script>	

</head>
<body>
<center>
<h2>Web Socket test page</h2>

<script>
var conn = new WebSocket("ws://localhost/ws.rsp")

conn.onopen = function(evt) {
 alert("Conn opened");
}
conn.onmessage = function(evt) {
 eval(evt.data); 
 }
conn.onclose = function(evt) {
 alert("Conn closed"); 
}


</script>

<button onClick="conn.send('Hello World');"> Send Message </button>
<button onclick="conn.send('makedrag');"> Make it drag</button>
</center>


<div id="test" style="height:100px;width:100px;border: 1px solid 
grey">MAKE ME DRAGGABLE</div>
</body>
</html>

-------WS.rsp------


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Welcome!</title>
	

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js'</script>

<script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js'</script>	

</head>
<body>
<center>
<h2>Web Socket test page</h2>

<script>
var conn = new WebSocket("ws://localhost/ws.rsp")

conn.onopen = function(evt) {
 alert("Conn opened");
}
conn.onmessage = function(evt) {
 eval(evt.data); 
 }
conn.onclose = function(evt) {
 alert("Conn closed"); 
}


</script>

<button onClick="conn.send('Hello World');"> Send Message </button>
<button onclick="conn.send('makedrag');"> Make it drag</button>
</center>


<div id="test" style="height:100px;width:100px;border: 1px solid 
grey">MAKE ME DRAGGABLE</div>
</body>
</html>

oops

WS.rsp  should look like this

<%

;-- RSP API web sockets specific changes --
;

;   request/web-socket? => true if this is an incoming socket message, 
false if it's HTTP.
;   request/content/data => contains the socket message (string!)

;-- just echo back the message
//prin request/content/data

inc: request/content/data
if inc = "makedrag" [prin "$('#test').draggable();"]  

if inc = "Hello World" [prin "alert('Hello back');"]
 
%>

Btw, the Internet Draft defining the web socket protocol (http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54) 
is really badly written. In particular, algorithm descriptions are 
incredibly obfuscated. On the design side, a packet-oriented protocol 
not sending packet length (for text frames), rather relying on begin/end 
markers, is a surprizing choice to me.

Terry: I'm glad you're enjoying your christmas gift. ;-)

yeah.. you've ruined my whole day :)