World: r3wp

You should be able to obtain an equivalent to REQUEST_URI by join 
several values from system/options/cgi.

join => joining

Except without being able to rewrite, the request_uri will always 
be the same...

If I type http://localhost/pages/this-- I need to run /cgi/qm.r 
and have access to '/pages/this'

I haven't delved deep enough to understand if this'd be better written 
as a Cheyenne handler, though that would require forking the cgi 
script, which for the time being, also has to run under Apache.

I see the problem.

If I give you a customized Cheyenne handler for QM that can check 
URLs (with parse rules) and send them to /cgi/qm.r before checking 
the local filesystem, would it suit your needs ?

Sounds good.

Isn't this how Zope works?

The whole Zope website is just a huge Python object, and when you 
access a path, the Zope webserver executes the object referred to 
...

But you can remap paths on the fly

Don't know how Zope handles rewriting, but the solution I've proposed 
to Chris is quite specific (even if it could be parameterized). The 
solution I had in mind for a Rewriting engine would be much more 
generic.

A few of us are experiementing with Chris' project .. so something 
that just sends everything to qm.cgi or qm.r would be helpful.

The Mod-MapURL that I'll provide in the next release will act like 
that, mapping URLS to REBOL objects (with nesting supported).

so, the application could just be a large object?  Or the objects 
are on disk?

in-memory objects

Ok.

From memory Zope has a disk based object database ...

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