World: r3wp

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.

so the "worker process".. is that the ws.rsp script itself?

think I need a diagram :)

The /on-done callback is for post-processing the response and decide 
what to do with it. It will be available in the new revision I'm 
commiting right now.

Here's a fun on-timer...

on-timer: does [
	x: read http://www.rebol.org
		foreach port clients [	 
			send/with x port					 
		]											 
	]

Worker process = task-handler process = background process = helper 
process, all different expressions for the same thing : a background 
REBOL process used for giving multi-tasking abilities to Cheyenne.

the browser is processing the complete html.. groovy

Yeah, you could make a realtime RSS feeder easily with web sockets.

SVN r50

FEAT: /on-done callback support added to 'do-task function in socket 
application.

FIX: socket application API now has more homogeneous argument passing 
(client port always first now).

Going now to see Avatar...will be back in a few hours.

Enjoy.. waiting for the line-ups to die down a bit :)

Nice work once again Nenad.

Thanks, it's fun to do and will probably be very useful for all Cheyenne's 
users.

Yes, awesome work.. and enjoy the Avatar .. I plan to go see it soon 
too

Just got home, were watchin Avatar 3D with friends and had some dinner.. 
 (Is there a group for movies?)

If not, create one. We have a music group, so why not.

I've often wondered whether I could use Cheyenne for doing upgrades. 
 So, for example my main application passes its own name, location 
and the upgrade download location to Cheyenne in a url read and then 
quits ...

Cheyenne then downloads the update, and writes it over the application 
( which has quit so it is no longer locked by windows ).