World: r3wp

If there's one thing I always have running on my monitor, it's the 
browser. I don't see much need for another GUI, including /view

I can envision a day when everything will have an "always on" connection 
with everything else that is important.. probably via websockets. 
 ie: my email, chats, voicemails pushed to me wherever i am, and 
on whatever device. The ability to do this is nothing new (SOAP, 
XML-RPC etc), but what is missing is a homogenous catalyst... the 
webserver seems the most likely candidate, as they are the de-facto 
interface to the world's DBs. This is my vision for Cheyenne, that 
of an Uber-server.

Oh, and LFReD driving Cheyenne's business logic :)

Hey Doc, have you seen Node?
http://nodejs.org/#about

I looked at Node a few days ago, interesting choice to see JS at 
server-side. I guess that the included 8k lines of C code help a 
lot having a decent speed. ;-)

Isn't that the included V8 VM?

From Node's sources, no trace of V8 VM, it's the Node network and 
event engine that's built in C for the most part.

It's like if the whole Cheyenne low-level layer (UniServe) was 100% 
built in C.

Interesting :-)

I thought node was Python?

FYI: I've implemented the web socket protocol in Cheyenne last night 
(not released yet) but I still need to figure out how to properly 
interface incoming data frames with the RSP engine.

That's really great!

Very cool Doc.

Is there a dummies for web sockets to explain what this does?

It's the evolutionary endpoint of Comet. It throws in special server 
and client support to enable them to keep an open, stateful connection, 
by switching an HTTP connection to what is effectively a lower level 
TCP connection

So it creates a bidirectional channel with only one connection, with 
good chances of penetrating firewalls

Cleans up the mess of the collection of hacks that is Comet

What's the reason why it should be able to penetrate firewalls?

Not familiar with Comet .. except as the name of my dog :)

So, if it opens a stateful connection, then I guess it is less able 
to scale to lots of users

And are people then running BEEP over web sockets?

It opens up the possibility to do similar things, yes, while still 
being able to fool firewalls

It has a good chance of fooling the firewalls because it starts as 
a normal HTTP connection

Since it's being standardised as web technology, there will be a 
big social barrier for firewalls to start blocking it

As a continuous connection, it's less scalable than regular HTTP, 
yes, but it's more scalable than Comet, which needs two connections 
for bidirectional communication, and other hacks

It scales better, as only a single connection is used.. in fact, 
Google is pushing it with Chrome for that very reason.

Comet is a diverse collection of hacks to create longer-term connections 
with Ajax

after the initial http handshake, there's no http headers included

Here's a good primer

http://www.indicthreads.com/3625/html-5-websocket-cracks-the-http-request-response-barrier/

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.