World: r3wp

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.

So, during the connection time, the target RSP script is not executed 
(unless you pass it a 'do-task in the 'on-connect handler). This 
target RSP gets associates with the opened socket until it's closed.

/on-done installs a callback handler (block! or function!) that gets 
invoked when the job sent by 'do-task to the RSP script is finished.

How do you pass a do-task to an rsp script? (what variables are passed?)

must it be the initial rsp script?

do-task takes a string! argument. You can pass anything you want 
using that value.

I put that "do %test.r"   in the timer without using do-task.. and 
it worked fine.. i guess that was blocking though?

You can also use the 'rsp-session object to permanently share values 
with the RSP process (to be usage carefully, see %ws-test-app.r).