World: r3wp

Marteen: for static 1ko files on a recent hardware, it should be 
around  500+ req/s.

I am thinking of RSP pages.

raw testing locally gives me : 188 req/s on /show.rsp

:-)

That's what Iw anted to know: in the 10s-100s/sec

AMD 3500+ (not the latest hardware)

There's still space for optimization...and R3 will make it run even 
faster ;-)

I need 3s to get 100 requests on show.rsp... but it's because of 
my FW

I saw wil reported 200 reqs/sec with an Ajax/DB (mysql) app on a 
dualcore

Those are good numbers. because data manipulation with your mysql:// 
is so much easier I think this will be much faster in development, 
deployment than most other web solutions. And performance is good 
enough.

Do you provide commercial support on Cheyenne?

Wrt session support: nothing stops me (or anyone else) to create 
a db-session lib that you can use from RSPs. The RSP model is inherently 
extensible.

Sure, you can bypass the internal session engine and use your own 
;-). Commercial support on Cheyenne, yes, that's a service we're 
already offering.

OK, I'll try to add some code that works database driven and mail 
to you.

Wrt  commercial support: what are the prices and what is the service 
(perhaps better to discuss this privately unless you can make a marketing 
statement ;-)

I'll contact you privately tomorrow about that.

its now official, I am starting work on the most significant (web 
side) module for cheyenne IMO.   remark engine integration   :-)

I don't know how rsp fits into the picture, but once I have something 
of a remark loadable lib working, I'll try to get others to better 
define how to merge rsp and remark (mainly what rsp can add to remark... 
things like session control maybe).  maybe rsp doesn't even become 
relevant... more details to come as I work out all the parts of this 
endeavor.  btw, this effort is brought up by need... not just hobby 
fun.

btw I use the url encode from graham and it works very well.

I also did an html-encode to allow easier form interaction... does 
anyone find a use for that?

(anyone *else*)

I'll be in like Flint...

btw... your cheyenne home page should be updated... the main link 
is wayyy old.

that was a message for doc... and sorry if reading it , it sounds 
like an order.. <phew> sooo not intentional...  the download link 
I mean, on the main cheyenne root page... you really should update 
that root page its seems to be like 6 months old now!

Max: glad to see you using Cheyenne too. About the home page, yes, 
it's still the old one, that's intentionnal for a couple more weeks, 
I want to reach a 1.0 beta first before putting the new Cheyenne 
out in the wild (that's why I keep the current releases almost confidential). 
Currently I want to focus on development and documentation, and only 
support a small group of early adopters (that's you guys ;-)).

A precision about modules : modules are executed in Cheyenne's main 
process (same process as UniServe and HTTPd service), so modules 
execution has a direct impact on Cheyenne performances. In order 
to obtain the best performances and best scalability, you should 
implement also what is currentle called in UniServe : a "handler". 
A handler in UniServe's context is a module executed in a background 
process, so it's not blocking Cheyenne's main process. A good approach 
might be to implement a module first, then export some of the most 
CPU intensive work in a external bg handler. That's the way CGI and 
RSP support is implemented. For a good example, see %mod-action.r 
and %handlers/CGI.r

If some of you needs to implement handlers now, just ping me here, 
and I'll write some preliminary docs on bg tasks API (quite short 
and simple in fact).

Btw, mod-action provides a general purpose background tasks launcher, 
you could use it for making your first "bg handler". Here's a small 
sample code for implementing a bg task handler called "demo" :

- Add in %httpd.cfg in globals section :

	bind-extern demo to [.dem]

- Add  %handlers/demo.r :

REBOL [
	Title: "DEMO handler"
]

install-module [
	name: 'demo
	
	on-task-received: func [data][	
		data: reduce load data
		wait 0:0:3				; simulates a 3sec long processing
	

  result: reform [		; you have to return the response string in 'result
			<html><body>
				"You're IP is :" data/ip
			</html></body>
		]
	]
]


- Then create a fake %www/test.dem file (with any content, not used 
in this demo handler)

- Launch Cheyenne and try : http://localhost/test.dem

The drawback of using mod-action is that you're tight to mod-action's 
communication dialect. If you need or want to pass other information 
between Cheyenne main process and the bg task handler, you have to 
write your own messaging dialect (quite easy, look at mod-action 
source code).

I know the "install-module" function name is confusing, all the UniServe's 
related function and concept naming will be updated shortly after 
Cheyenne 1.0 to be more simple and less confusing.

Notice one important thing about bg handlers programming, you should 
have exactly the same handler name and handler filename (watch out 
for case-sensitive filesystems).

Hey Doc, thanks..
One thing I was trying with Uniserve years ago went like this.. 
1) A http request is received as usual. (port 80)

2) Depending on the request, Uniserve would launch a process that 
may run for hours (ie: reading a website looking for changes), and 
would occasionally send a message back to the ip address, but on 
a different port (communicates to a flash script on the original 
response page, that in turns manipulates the DOM.)


So, what's the best method to run these small scripts as to not block, 
and close without closing the server. 

I still want to serve up an HTML response, so it's a hybrid of sorts.. 
sends back a page AND runs it as a handler too?

UniServe is based on the classic request/response model. You have 
to implement a specific UniServe' service for your specific need 
(like sending a response to another client than the one who sent 
the request). I guess you'll have to maintain in the service's context 
a list of the (browser, flash) connections couples, so there's some 
probabilities that you'll end up write a full custom HTTPd service.

write = writing

thanks for the info about bg stuff.  right now I will be concentration 
on reformating remark so its a loadable module... a few details make 
it more complex than it could be.  (remark being so flexible).

Doc, I guess my question is, how can I pass a message from a module, 
to a Uniserve service?

uniserve/shared space or a global function.

are there docs on the shared space?

no, uniserve/shared is just an object, so you can add whatever you 
want in it using the uniserve/share function.

Cheyenne's RSP API Reference doc updated: http://softinnov.org/tmp/rsp-api.html

isn't the value triger in http protocol (4000) too low?

trigger

Are you talking about the SERVER-PORT's example in the doc ?

not in doc... it's more related to uniserve

It should be safe to push it higher in order to increase the bandwidth. 
Let me know how it reacts.

I changed it to value 10240 - the change is not so visible but I 
think it's better as there is not so many on-stream-in calls

An application is just a subdirectory right? And it always requires 
a login?

If so, is there a way to bypass the login>

Take a look at testapp/login.rsp.  I think you just need to session/content/login?: 
yes and response/redirect/ "/theapp/" to get round a login form.

always requires a login

 : no, just remove or comment the 'auth "..." part  in config file.