World: r3wp

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 ).

My rebol is rusty.. Keep adding semi-colons to lines of code

Just fooling around.. there's some interesting behviour here... 

changed the on-timer function in  ws-test-app.r file to... 

	on-timer: does [								
		foreach port clients [						 
			out: do %test.r
			send/with out  port				 
		]										 
	]


.. and created a test.r file in Cheyenne's root thus.. 

rebol []

a: "42"
b: "43"

out1: rejoin ["OUT1: " b]
out2: rejoin ["out2: " a]
out1

seems whatever the last thing that is "done" in the test.r script 
becomes the response message.

append this to the end of test.r 

{hollow words}

and that's the response

What is cool, is that there's no need to reload the Cheyenne config 
files.

Graham: yes possible, but maybe overkill, a simple one-page script 
might do the job fine, no?

Well, currently I download the update and then write a command script 
that deletes the current application, and then renames the download 
to the application name, and then starts it up, call the command 
script and quit.  
But forwhatever reasons .. it often fails

due to a file lock on the application ... maintained by whatever 
...

so instead of using a command script .. I thought  I could use Cheyenne 
instead as that is always running.

If the script then fails, it could check to see if the application 
is still running and kill it somehow.

Is this correct, that I do not see any output in the console of a 
cheyenne instance started with -vvvvv, when I click on the "Send 
Message" button of ws.html?

Sorry, I just realized, that FF does not support them.

Chrome 4 only currently.