World: r3wp

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?

Doc, can you use do-task within the .rsp page?

And timers?

PHP: quite stable as long as you don't do live %httpd.cfg file reload 
(mess up PHP processes).

do-task in RSP : no, UniServe's model is : one unique dispatcher 
process, one or many worker process.

Timers: no, they require an event loop, worker processes can't have 
one because they are supposed to work in a request/response model.

What's the need to have timers in RSP script when you have it already 
in socket applications?

Another question.. lets say i have two clients connected via websockets.. 
.remote-ports 3450 and 65480
How would i pass the message from one to the other?

Btw, in the current SVN revision, it's not possible to call 'do-task 
from 'on-timer event.

Need some port managment layer I suppose.

You already have it.

It's minimal but it should cover all needs.

What i mean is a layer that associates ips and ports with sessions, 
pass these on to a db etc.