World: r3wp

ahh.. that is the problem

I replaced url-encode with my own function, and it works fine now.

sweet

Not sure. Change this inthe RSP and see what happens: print rejoin 
[ "Dehex: " dehex head test <br/> ]

Graham: submit your own function here so Doc can include that in 
the next release (and we all to in the meantime :-)

this is straight from the cookies-client.r

url-encode: func [
    {URL-encode a string}
    data "String to encode"
    /local new-data
][
    new-data: make string! ""
    normal-char: charset [
        #"A" - #"Z" #"a" - #"z"
        #"@" #"." #"*" #"-" #"_"
        #"0" - #"9"
    ]
    if not string? data [return new-data]
    forall data [
        append new-data either find normal-char first data [
            first data
        ][

            rejoin ["%" to-string skip tail (to-hex to-integer first data) -2]
        ]
    ]
    new-data
]

Thanks Graham, I'll look at your code and fix my url-encode function 
asap.

I think tomc wrote the original version about 1999 or so !

Proven technology ;-)

I use:
url-encode: func [
    "URL-encode a string" 
    data "String to encode" 
    /local new-data
][
    new-data: make string! "" 
    normal-char: charset [
        #"A" - #"Z" #"a" - #"z" 
        #"@" #"." #"*" #"-" #"_" 
        #"0" - #"9"
    ] 
    if not any [string? data binary? data] [return data] 
    parse/all data [any[
    	  copy tmp some normal-char (insert tail new-data tmp)

     | copy tmp some #" " (insert/dup tail new-data #"+" length? tmp)
    	| copy tmp 1 skip (

      insert tail new-data rejoin ["%" as-string skip tail (to-hex to integer! 
      to char! tmp) -2]
    	)
	]]
    new-data
]

I think Will's mod-rewrite does what I want. Perhaps I can test and 
document it :-)

Marteen, about your questions, there's currently several web sites 
running with several months uptime. Cheyenne is quite resistant to 
all classic web attacks (tested with the Nikto package). About speed 
and performances, I've done a few test a year ago but a lot of things 
changed since, so I need to do some new benchmarking (anyone tried 
with Apache's ab tool ?)

but it could be modified not to create new data but rather modify 
the existing value.

Thanks. I suspect 100+ reqs/sec should be easily doable

Oldes, thanks, I've made a minimal url-encode function (due to lack 
of time). I'll wrote a better one for the next release. Not sure 
what approach is faster, changing the argument series or building 
a new one...will test that.

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