World: r3wp

req/out/code

lacks : req/out/code: 200

and delete the : if all.. line

Eureka!

this line is for testing in mode-rsp/make-response if the request 
should be processed by mod-rsp or not.

That should be Rebol's new name ;)

Agreed ;-)

That's great..   so very extensible.. I have a really basic core 
Chyenne, and can add mods as I go..

Well, I guess it's good as it's not crashing now.

I wonder if it was because I had some paths wrong to the javascript 
libraries ...?

Trimming out the extra modules really sped things up.. doing 1000 
localhost page hits in < 9 secs

Would that kill the rsp engine if it tried to include non existent 
libraries?

Cannot make it crash whatever I do...Anyway, if you can reproduce 
the problem, I'd like to know what caused your error.

humm, good question :-)

might be the cause, let me try that

I originally had relative paths .. but the Yahoo libraries were above 
the webroot

so, I switched then to using absolute paths to Yahoo itself

I wasn't sure if rsp would allow me to include outside the webroot

currently, there's no restriction on that, but I have to sandbox 
those include functions.

Hmm  ..that's not correct.

Oops.. that was < 9 secs with vv debugging on.. turned off it was 
< 4 secs

rsp would include the file correctly, but the generated page would 
reference libraries outside the webroot

Tested here, seems ok, I got an RSP catched error telling me that 
the file is not found.

I'll play some more and see if I can reproduce .. though I would 
prefer not to see more errors :)

Ran 3 scripts concurrently doing 5000 page reads each  .. all 3 finished 
around 33 secs.

Any idea on concurrent user limits?

I've done some stress test on a previous version of Cheyenne, it 
was sustaining around 500 concurrent connections on static pages 
requests. (RSP have a limitation of  <500 due to a design bug in 
task-master. This bug will be fixed in a few days).

I need to do more stress tests on that to publish officialy Cheyenne's 
performances.

Btw, the testing tool was written in REBOL, it may have some bugs. 
I'll do more serious testing using third-party stress test tools.

sessions: Is it possible to add a cookie-free session handling by 
adding a session ID to the URLs?

I like the way I can omit many print statements by escaping out of 
the rsp as follows

<%

 qry: rejoin ["select age, diagnosis from diagnoses where patient 
 = " session/content/uid ]
	sql: do-sql 'remr qry
	if not empty? sql [
		%> <table border=1><tr><th>Age</th><th>Diagnosis</th></tr> <%
		foreach record sql [

   %> <tr><td> <% prin record/1 %> </td><td> <% prin record/2 %> </td> 
   </tr> <%
			response/flush
		] 
		%>
		</table> <%
	]
%>

Robert, you can still track the sessionid

or, does that need cookies???

Not that I know about. But I have to do it myself, right?

Or is there an option for RSP to use cookie or session-id?

try turning off cookies and see if the session id is preserved

I would guess not

Graham: instead of writing <% prin record/1 %>, you can use the following 
syntax : <%= record/1 %>

Session currently only use cookies. The session ID is available (session/id) 
so you could embed it in urls, but session cookies support is hardwired 
in the RSP engine, so it would require a lot of internal changes 
to not rely on cookies.

Btw, why would you pass session ID through URLs instead of cookies 
? Is it for users that wrongly feel more secure by not accepting 
any cookie ?

<%= - nice ... that'll save a bit of typing :)

Note: so long as QM is server neutral (i.e. it's Apache friendly), 
it will not be as efficient as it could be under Cheyenne.  I really 
would like to do a Cheyenne-only version, but not until QM is feature 
complete (and I will say 'stop' as some point :)

don't loose your time with apache.. 8-)

Unfortunately it's a requirement :(

How does Cheyenne's performance and security stack up against the 
other indians (Apache, Cherrokee, Hiawatha, ...)?

Most of QM is just establishing the core functions and protocols. 
 I could just sweep them away if they were preloaded.

Doc, exactly. A lot of companies don't allow cookies for their employees...

I would fire IT person who has anything against cookies ...

Any decent antispyware program will delete the worst ones - the rest 
should be OK.

Of course that is on Windows.