World: r3wp

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

Graham: I have a client application using a similar method to do 
updates.
Once the update exe is downloaded :

write/binary %application-maj.exe decompress res
wait 0.5						
call "application-maj.exe"						
quit

Then, the first thing the application does when started is :

if find system/options/boot "application-maj" [
	delete %application.exe
	call/wait "copy application-maj.exe application.exe"
	wait 0.5
	call "application.exe"
	quit
]

if exists? %application-maj.exe [
	attempt [delete %application-maj.exe]
]

I think the issue occurs when the user runs two copies of the application 
.. so it can never be deleted.

I see your way dispenses with the need to run a command script.

It's working ok, but in fact, the only 100% reliable way and most 
efficient way of making updates is by downloading new REBOL source 
code in encrypted format. Your exe becomes then basically a "loader" 
with a built-in default version of the application. On each start, 
it should scan online for new versions and scan local disk for cached 
updates.

Yeah .. I think that's what Gabriele has suggested in the past.

The other way I used to do it was maintain binary diffs and xor them 
back to update the main binary .. but again that requires the user 
not to run two copies :(

BTW, since rebol code is already compressed .. .do you gain much 
by compressing it further as in above?

REBOL code payload is compressed but not the REBOL kernel compiled 
C part. The gain is around 40% in my case.

How stable is Cheyenne's PHP handling these days?