World: r3wp

Thanks Doc.

Look in %Cheyenne/mods/mod-expire.r

Cheyenne needs a message broker for websockets... task-master?

well, to counter the dead-locks, we could have a new sort of attribute 
for functions like [ATOMIC] or [SINGLE].
That will prevent a function to be interrupted by other tasks.

or maybe 2 new functions, to disable and enable tasks interrupts, 
would be enough (like in some ASM)

or FORBID :-)

Davide: dead lock is not a fatality, threading support can be implemented 
correctly to avoid such issue (but with possible restrictions). As 
usual in software design, it's a matter of tradeoffs.

Btw, both OS threads and light threads are desirable and useful features, 
IMO.

yes, I agree on OS and light threads (coroutines or something)

Terry, wait to try the new web socket framework I'm working on. It 
should be ready tonight (if I find time to finish testing and debugging).

Sitting on the edge of my chair :)

me too :)

SVN r46 : web socket application framework released.

It's unfinished, but I try to follow the motto: release early, release 
often. At least, you can get a taste of how it looks like. Simple 
 test application with lots of comments here : http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/www/ws-apps/ws-test-app.r

It's basically an addition to the supporting code added a couple 
of days ago. It defines an application container that is loaded in 
Cheyenne main process to interact closely with all connected clients 
while permitting background tasks execution using the initial RSP 
script as target (%www/ws.rsp in the example). No change on the RSP 
side.

I have to make some time to play. Very cool Doc. Thanks for posting 
early and often.

There's also now the ability to define a timer per socket application 
to generate server-side events (powered by my scheduler library).

Thanks Gregg for the support, the more eyes on this, the better it 
will be.

Thanks for including all the comments in the code too!

That's poor's man documentation but as it is a brand new framework 
and still fresh in my mind, it's better to get it writtten down now, 
even if it's a draft.

Btw, you can test this socket app using the two test script (look 
at the source code to get an idea) :
http://localhost/ws.html
http://localhost/ws2.html

I'll finish the pending items tomorrow and will try to provide a 
more fancy example by building a realtime web chat application.

Why 'deconnect rather than 'disconnect?

As a word choice that is.

Ah good one, maybe because I read 'disconnect used in a framework 
somewhere and my mind stored "deconnect" (almost french word for 
'disconnect). I'll fix that asap.

Spelling issue fixed in SVN r47.

Run Cheyenne in verbose mode (-v is enough) to see how the browser 
and the server interact.

Which version of Rebol is required? Im getting an error with View 
2.7.6.3.1

Script: "Cheyenne Web Server" (8-Mar-2009)
Script: "Untitled" (none)
make object! [
    code: 300
    type: 'script
    id: 'no-value
    arg1: 'scope
    arg2: none
    arg3: none
    near: [either root: select scope 'root-dir]
    where: 'read
]

(winxp)

same issue here

I forgot to commit one file.

Fixed in SVN r48

SVN r49 :

FEAT: socket's 'on-message event now receives also the client port 
as 2nd argument
FEAT: RSP session access added for socket apps.
FEAT: minor memory usage reduction in mod-rsp.r.
FIX: additional 'disconnect misspelling fixed in HTTPd.r.

Working fine now. Seems very stable. Can only get a websocket connection 
on localhost, no connection from another computer on the same subnet.

Good to heard. I'm still making a lot of small changes and fixes, 
so it's should not be considered fully stable yet.

The ws://localhost/ws.rsp URL is hardcoded in example pages. Just 
change the JS code to point to the adequate domain of your server 
to be reachable from the LAN.

heard => hear.

In your example, what is "do-task data" in the on-message function 
doing?

(ws2.html)

'do-task processes the argument data...
  what does it process? Rebol?

Great, first you spoil my christmas break, now New Years.

:-)

'do-task sends the argument string to a background worker process, 
so you can do whatever you want with it without blocking the main 
server. The target used is the initial RSP script (ws.rsp in the 
example).

do-task allows you to have multitasking in you web socket application. 
Internally, it  re-uses the task-master service and the RSP IPC system. 
That way, you can easily integrate one or several web socket service 
or applications in existing RSP scripts or webapps.

the "data" argument can contain anything as long as it's a string! 
value. It will be available on the RSP side in request/content/data.

so do-task in your example would simply echo back to the browser?

and ws.rsp is more like a message broker?

do-task in this example, sends the raw incoming data from the browser 
to a worker process using ws.rsp script to generate a response that 
is sent back to the web socket app (if a /on-done callback has been 
defined) or directly to the client browser.

In this simple example, right, the backend RSP script acts as a message 
broker.