World: r3wp

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.

The current framework gives you access to client ports value, RSP 
session object associated with a client, RSP script execution (with 
'do-task).

Database accesses should be done in RSP scripts (because they are 
usually too time-consuming).

Btw, if you need to keep client specific data, it's quite simple. 
Here's an example (untested) : 

users:  make block! 1
session-class: context [hits: 0]

on-connect: func [client][
	if not find users client [
		repend users [client make session-class [ ]]
	]
]

on-message: func [client data /local ctx][
	ctx: select users client
	ctx/hits: ctx/hits + 1
	...
]

on-deconnect: func [client][
	remove/part find users client 2
]

sorry: on-deconnect => on-disconnect

Ideally, I guess all the socket control scripting should be done 
within the 'socket-app.

I was thinking this would make a great proxy to a remote server for 
futher processing... but how to pass the arguments?

Futher processing

 can be done in RSP scripts in worker process, that's what they are 
 meant for. If you need to connect to a third-party server, arguments 
 passing depends on the communication protocol required.

I think I'm lost (happens all the time).  Let's say I want to poll 
a remote web page for screen scraping (or remote php processing) 
every 2 seconds, and pass that to a specific port.. I would do this 
from the 'socket-app, no?

Now lets say the client hits an event on the web page, and now i 
want the timer to visit a different remote web page.. how would i 
pass that event to the timer?

You would generate the timer events in the socket-app, pass the job 
to do to an RSP script, and use the /on-done handler to send the 
response to the client you want once the RSP script finished its 
work.


(this will work once I fix the issue with 'do-task calls from 'on-timer 
events).

The timer is just an event generator, you can't pass data to the 
timer. You need to store such info in a user session (a block! or 
object! for example).

Ah.. i figured out where Im lost!  It's at the "generate a timer 
event", "pass the job to an RSP script" and the "use the /on-done 
handler" bits :)

:-)

Once I figure this out, I'll paste a layer on top of it for noobs 
like me.

I guess it will be more clear once I make a few demo apps and write 
a doc for the new API.

I started a diagram at least 
http://www.gliffy.com/publish/1943806/

Just need to fill in the arcs :)

Both blocks in your diagram should be on the same horizontal line, 
the ws.rsp block should be behind, it's part of the backend while 
ws-test-app.r is on the frontend.

should => should not

SVN r51
FEAT: /ws-apps folders are now protected from direct access.

FEAT: modified socket apps source files are reloaded and used by 
new clients.

FIX:  web socket application's 'session object renamed to the more 
accurate 'rsp-session.
FIX:  'do-task calls now supported in 'on-timer handler.
FIX:  scheduler issue with deleted jobs.

Moving right along :)

ooh.. the diagram is looking shiny

Part of the confusing bit is the ws.html connects to the ws.rsp script 
first.. I would have thought of it as on the front end.

I agree that's a bit confusing.

how does /on-done work?

That comes from the way web socket's connection are initiated, it 
starts like a simple HTTP GET request and the server is supposed 
to validate that request, check access authorization if required, 
etc... So, to avoid duplicating work, I choose to re-use RSP framework 
as much as possible. The initial ws:// URL must point to a valid 
RSP script so that the server can check, for example, RSP session 
cookie for access rights.