World: r3wp

running their own app server (mongrel/thin/unicorn) helped a littlebit, 
but they couldn't easily test what was returned just by the webserver 
from cache / static files

the main problem with my setup was always the autonomity of the users

i had to edit config files when a new user joined the company

and i had to be aware where are they checking out the source of the 
projects they were working on and i also had to assign port numbers 
to them, so i could configure the reverse proxy in apache/nginx to 
connect to their app servers

Your need is pretty clear.

You could do the same (reverse proxy/nginx) with Cheyenne instances.

security in such a case is not a big concern (unless the machine 
get rooted :)

Cheyenne just needs to be able to pick the config file from a remote 
folder instead of just current one.

sure, but i would love to get rid of any external component, since 
cheyenne seems to be pretty close being able to cater for such a 
setup

Where would Cheyenne binary be in your scenario?

/usr/local/bin/

or sbin

then how could Cheyenne know where to look for config file ?

the only way I see is passing the config file path as command-line 
argument, something like:
cheyenne -p 8001 -conf /home/devel1/app/current/

Would such feature cover your needs for user autonomy?

if it still looks in the current directory for a httpd.cfg by default, 
then it's not even necessary

cd approot; cheyenne

cheyenne --conf approot

not a big difference

doesnt worth the trouble, i guess

is approot linux specific?

why not a mod_log  ;-)

might still be needed for MacOS X servers?

by app-root i mean that directory level which cheyenne will never 
try to reach above

ok

any relative path in a config file is normally calculated from there

again, why not allow these configs in the httpd.cfg file?

because, the httpd.cfg place is unknown to Cheyenne in this case 
;)

ah so you're talking about the embeded mode?

or then... what is "this case"  I'm obviously missing something here 
 :-)

nope, see the piratepad link from onetom, we were talking about relocating 
the whole Cheyenne working folder.

Dinner time here...

ahh.  k.

were we talking about such things? really? :D

this mod-userdir name is a bit misleading, i think. i was expecting 
some handler for the /~user/  pathes and the ability to automatically 
fire up workers with the right ownership based on the owner of the 
directory it's serving from

however, since the source version runs again with /core, i can hack 
whatever i want now

i just need the logs go out of the way in a binary version

in the binary versions

Doc, is it safe to do this:

req/in: make req/in [
	data: value
]

within any/all of the module phases?

safe in the sense that some code in uniserve/cheyenne might have 
an absolute reference to the req/in... and this could break the chain 
of command..

I think that it is safe, but you should test if Cheyenne still works 
correctly after such change anyway (too bad we don't have unit tests 
for checking in such case...;-)).

hm... i miss the "restful" routing layer :)

i would like to have rebol files with an object in them -- like asd.r 
qwe.r -- returned as json via the path /asd and /qwe

i was thinking making a webapp which returns on-page-end the to-json 
context load rejoin [%. request/parsed/file %.r]

but i get a 404 in an earlier step, i guess

i have a couple of ideas how to hack this, but what would be the 
"correct" way?

capturing 404 doesn't work because it won't know the url of the original 
request

hmm.. now how can i write a module for the binary version of cheyenne? 
can i?

I think the original URL should be in the INTERNAL_REFERER header. 
At least that's how I'm using it in my situation

That's with the (REBOL) CGI interface. I don't know if there's an 
easier way in RSP