World: r3wp

All the application in a large object, if you design it like that, 
sure.

How's sessions going? :)

Yes, I know about ZODB, quite interesting OODB.

Very well, I'm currently testing the whole RSP framework by building 
a "test" application : a new web-based bugtracker ;-)

It helps me tweak the session system and add some small but useful 
features.

bootstrapping ?

Anyway, sounds like progress is being made :)

Yes, I quite happy with the speed and stability of the new implementation, 
I have RSP pages with 3 SQL queries to a MySQL backend, input and 
output filters, session handling, tables constructed dynamically 
with data from DB, all this occuring in a few milliseconds...I still 
need to test how it scales.

I => I'm

RSP now supports a thin layer for easier DB access. No need to open/close 
connections, they are persistent and pooled.

As soon as the bugtracker is ready, I'll put it online and release 
a new beta of Cheyenne.

I think I just opened a connection from start up and kept it open.

The "thin layer" I was talking about doesn't do much more than that, 
but it's done in a clean and handy way, and once for all.

ok.

I'm finishing a mod-qm for Cheyenne. I'll need to test it and will 
drop here a download URL.

Nice

hum, problem with [get-env "REQUEST_URI"], I can't set-env ! Is there 
a simple way to set an environment variable from REBOL ?

no

I think you can set it for the session, but as soon as you reboot 
.. it's gone.

If not it can't run under Cheyenne without changing qm.r...but Chris 
said it has to work with Apache...:-(

kernel32: make object! [ lib: load/library %kernel32.dll win32api-GetEnvironmentVariable: 
make routine! [ name [string!] buffer [string!] size [ struct! [ 
size [integer!] ] ] return: [integer!] ] lib "GetEnvironmentVariableA" 
get-env: func [name [string!] /local size][ buffer: copy "" repeat 
sp 255 [buffer: append buffer " "] size: make struct! [size [integer!]] 
reduce [length? buffer] win32api-GetEnvironmentVariable name buffer 
size trim buffer ] win32api-SetEnvironmentVariable: make routine! 
[ name [string!] value [string!] return: [integer!] ] lib "SetEnvironmentVariableA" 
set-env: func [name [string!] value [string!] ][ win32api-SetEnvironmentVariable 
name value ] ]

making a custom module if just not enough, I need a way to set  "REQUEST_URI" 
env variable.

thanks :-)

except we are all testing under linux!

doh!

here's another one ...

kernel32: make object! [
lib:  load/library %msvcrt.dll

get-env: make routine! [
	varname [string!]
	return: [string!]
] lib "getenv"

put-env: make routine! [
	env-string [string!]
	return:    [integer!]
] lib "_putenv"

remove-env-var: func [name [string!]] [put-env join name "="]

env-var-exists?: func [name [string!]] [
	either "^@" = get-env name [false][true]
]

tz-set: make routine! [
	return:    [integer!]
] lib "_tzset"

free_lib: does [ free lib ]

]

since they both work while the app is running, I guess that's okay 
for windows.

Thanks, but still for win32, do you have one for linux ?

aren't linux env variables just disk files ?

don't know, possibly, but I'm on Windows, I can't test that for now...

http://www.linux.com/howtos/Secure-Programs-HOWTO/environment-variables.shtml

maybe that will help

Looks like it's stored in memory only : "In short, environment variables 
are internally stored as a pointer to an array of pointers to characters; 
this array is stored in order and terminated by a NULL pointer (so 
you'll know when the array ends). The pointers to characters, in 
turn, each point to a NIL-terminated string value of the form ``NAME=value''"

so need some wrapper script to set the env variables?

yes, /usr/bin/env

The problem is that 'REQUEST_URI' is Apache specific, it's not part 
of standard CGI...

I'll see how to handle that when my CGI generic module will be ready 
(for Cheyenne 1.0).

Sorry for QM, I don't have a simple solution to integrate it with 
Cheyenne, for now.

here is mod-rewrite for cheyenne http://reboot.ch/mod-rewrite.r

althought it may need some changes in cheyenne's core as well

I don't need Request_Uri specifically, just something that acts that 
way.  When I say I don't want to fork QM, I mean the script -- a 
few 'if find request/server-software "Cheyenne"' calls are not a 
problem.

For example, if there was a way of hijacking 404s, passing the 'request 
uri' as do/args to %qm.r, that would work too...

I customized 'mod-rewrites'  for Cheyenne by intercepting the requested 
file in httpd.r  works great.. much more powerful than Aoache's mod-rewrite. 
 Same would work for 404s

Doc, Chris, Cheyenne could just redefine get-env, couldn't it?

This gets it working, but doesn't honour existing files.  mod_qm.r 
(with qm at the top of the list of modules in httpd.cfg):

REBOL []

install-HTTPd-extension [
	name: 'mod-qm

	order: [
		url-to-filename last
	]

	url-to-filename: func [svc req conflo][
		req/in/path: "/"
		req/in/target: form req/in/file: %qm.r
		req/file-info: info? req/in/file
		req/handler: select svc/handlers req/in/ext: '.r
		false
	]
]

Then in the CGI handler, I changed this line (just to see if it works, 
not as a recommendation):

soc/path-info: data/in/url

Finally, in the 'request object in QM, I changed the Request_Uri 
line:

path: any [path-info get-env "REQUEST_URI"]