World: r3wp

Doc.. Im just thinking scalability / benchmarking.  I plan on spending 
my spare time over the next number of months building a next gen 
webserver using Cheyenne as the core, and I want to make sure I don't 
hit a game killer 3 months in.


i posted earlier in the Rockstar group how superior Cheyenne is compared 
to vhosts and .htaccess.. night and day.

With R2, there's not much that can be done. The performances can 
be improved a little, that's all. You can still build clusters of 
Cheyenne server to sustain a higher load (obviously the front-end 
dispatcher would have to be done in C, there's several good ones 
in open source, or if you can afford, using an Alteon-like box). 
With a completed R3 (w/multithreading), Cheyenne could be a real 
competitor to Apache 2.

It is my personal belief that the HAL 9000 started life as a Cheyenne 
web server.

Yeah, you can round robin.. all sorts of options.. I think Apache 
handles 4000 concurrent connections?

Just a question about webapps... can we provide access to these also 
by basic authentication?

Suppose I implement the rest-mod, I want it be stateless so no cookies. 
 I want to pass the userid and password each time.  So, with no cookies, 
the user won't have access to the webapp.  So, does this mean I can't 
use a webapp with rest-mod?

Basic auth: it's not built-in but can be added in your RSP script.

or in mod-rest ?

right

If you're stateless, you don't need to use webapp (<=> session), 
simple RSP scripts would be enough, no ?

ok

yes, I think so.

just thinking thru the issues :)

included files can't contain RSP can they?

they're just processed as straight text ...

no cookies => no access to webapps (unless you inject them in mod-rest...;-))

http://cheyenne-server.org/docs/rsp-api.html#def-21

you can include either RSP (will be executed) or static files.

oh ...

I'm sure I read somewhere that included files are just processed 
as text.  Must have changed?

mutualize => share

More than a year ago.

not such word as mutualize

Ok .. I'm out of date!

oh, thanks, fixing that.

and I need to re- RTM

Fixed.

can I have an account on the wiki please

sure

my email is good ...

value: request/posted

    returns a binary! value.
is incorrect I think

From memory, it returns a binary! or string! value

If it's a file saved to the web server as it's too large .. it's 
a string! holding the file name in %incoming/

Are there any instances where Cheyenne would redirect back to the 
previous page if there was an error?

Your API reference is not part of the wiki .. I can't amend it! :(

Henrik  .. why would you want that?

Main Menu / Using RSP ;-)

Graham, I don't. Cheyenne is doing that right now on a new page I 
just created. The first version had a flaw that would not let it 
include a specific rebol include. Now I fixed it, but it keeps "bouncing 
away" from the page.

older rsp pages work fine

Henrik, is this an untrapped RSP error?

request/posted : I'm not sure, looking at the source code...

either string! = type? request/posted)[
		; file name as large post
		f: trim/tail find/tail request/posted "incoming/"
		file: join %../incoming/ f

  write/binary to-rebol-file rejoin  ["faxes/" filename ] read/binary 
  file 
	][
		; binary content

  write/binary to-rebol-file rejoin  ["faxes/" filename ] request/posted
	]

Henrik: never saw such kind of issue yet.

Error 500
Access Error
Cannot open <my file here>
Near do %../../html.r
Where: protected-exec

http://rebol.hmkdesign.dk/site/pages/<-- try this page

Henrik, I've had some issues with relative paths and 'do ... in Cheyenne 
'do is a mezzainine with different bindings.

If you need to use 'do ... use *do

Graham, possibly, but I use this method in about 20 other rsp pages 
without problems.

version ?

From v0.9.19, using 'do would by default bind your loaded code to 
the webapp context (and not to the global context). Btw, if you're 
using an external INCLUDE function, it may clash with RSP's global 
INCLUDE function.