World: r3wp

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

I've fixed several issues with timers, so yes probably. I still don't 
get why you want to "do" a script on each event...

to be usage => to be used

i was just experimenting.

(as far as putting the "do" in the timer)

As for "do"ing a script with each event, I suppose the traditional 
way would be put all your code in the ws.app.r ... do ing was more 
like "include"

The last revision will auto-load your socket app if you've modified 
it, but only new incoming connections will use it. Established connection 
will still use the older version. Once every client disconnects from 
the old version, the old app version is dropped out.

Ok.. i'm officially digging Cheyenne's websockets

some examples coming down the pipe

Here's a modified on-message from ws-test-app.r 

	on-message: func [client data][						
		;send data
					
		do-task/on-done data func [client data][	 
		

   ;data: do/args %/c/cheyenne/cheyenne/test.r {one "two three"}		  
       ;doing a script passing /args

   data: read http://www.php.net/usage.php				      ;as 
   a proxy to PHP server
			
			send/with data client
		]
	]

and the test.r script... (drop in Cheyenne's root)

rebol []
 
x: to-block system/script/args
 
to-string x/test