World: r3wp

s it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

 Yes, .r scripts are processed as plain REBOL scripts but with the 
 addition of the whole RSP API since r100 (http://code.google.com/p/cheyenne-server/source/detail?r=100).


It has been officialy documented on the wiki only recently: http://cheyenne-server.org/wiki/Rsp/Basis
("No-template scripts" section).

Doc, did you get a chance to debug fast-rebol-cgi?

my quesstion was rather: where and how is it hardwired that .r is 
executed in rsp context? is there an internal bind-extern RSP [ .r 
] happening. do i need the rsp module for this alone or do i need 
that action module too? stuff like that. otherwise it feels pretty 
magical

we have even experienced very strange behaviour with the
unless value? 'some-func [ do %../lib/obj.r  do %../lib/oid.r ]

tactic. our to-object function defined in obj.r didnt have a value.

we modified the script, did not restart cheyenne and it started working!

it was just happening with the binary version of cheyenne, iirc, 
so i dropped the case...

Kaj: I thought it was fixed since r131: http://code.google.com/p/cheyenne-server/source/detail?r=131

AFAIR, mod-action is required for mod-rsp. bind-extern RSP .r is 
required to send .r scripts to the RSP handler in workers.

See April 25 above. I used r135:

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

so, if there is no bind-extern RSP [ .r ] then where are the .r files 
get executed? within the main cheyenne process?

onetom: They should be just served as a static resource if the 'bind-extern 
directive is not used.

Kaj: I'm looking into that issue right now.

Kaj: I've pushed a fix in r137 for fast-rebol-cgi. It was wrongly 
defined as a Globals section keyword instead of a Host section one.

Ah, I was wondering about that

So I have to define it for every applicable host?

Yep.

Thanks, I'll try

By the way, I still want to get rid of the loading of the REBOL CGI 
script on each request, even though I've minimised its size. It's 
a fallback script that now executes in the not-found handler. If 
I would change it from a fast-rebol-cgi script to an .r script, and 
put it in an ALIAS handler, would that preempt the loading of the 
script one each request? I'm not using the RSP interface, so the 
loading of that would be extra overhead. Would it still be faster 
than loading the small fast-rebol-cgi script?

Hard question for past midnight, I think you've lost me after the 
first sentence. :-)

Oh, I thought I was the amateur. :-) Maybe a night sleep will enable 
you to answer it?

What are you calling the "not-found handler"?

404 status

Ok.

Same way QM hooks into Cheyenne

I mean, RSP templates are cached, right? So are the new .r files 
cached, too, instead of loaded on each request like CGI scripts?

RSP templates: yes, .r files: I'm not sure, checking the code...

.r: right, they are cached too when they are evaluated by the RSP 
handler.

Cool, and refreshed when modified?

Sure.

If I would change it from a fast-rebol-cgi script to an .r script

 I understand you want to use the RSP handler instead of the CGI handler?

So do you think preparing the RSP interface for each request would 
still be faster than reading a small rebol-fast-cgi file every request?

Yes, if that would be faster

Hard to say, the RSP "preparation" overhead is much bigger than for 
CGI, but OTOH, the CGI script is not cached in memory...

I thought so. I'd have to do measurements to be sure

At least, not explicitly cached, but it will probably live in the 
system memory cache for disk files, so hard to say.

Thanks, that clears it up as far as we can get now

It works. I'm now running the binary version of Cheyenne instead 
of the source version

That should mean I will now be able to use the 0MQ binding

hmm... i thought i can put my shared library code above the webapp 
root, but it seem to fail without any errors.

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
i don't quite get that depth/1 and arg/3 stuff

i was moving a plain .r script which was aliased in a vhost context 
under a webapp and it started to fail because the 'do didn't seem 
to work properly

REBOL []  do %../lib/obj.r  probe to-object [a: 1]

obj.r defines to-object but i get a
        ** Script Error : to-object has no value

i moved the library stuff into on-application-start, but still it 
wasted me a lot of time to realize that the 'do is overwritten in 
RSP and works specially (as in, it does not work) in webapp context

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
 Bind the loaded code to a special per-webapp context.

A webapp execution context is isolated as much as possible from the 
rest of the vhost.

set 'do func [[catch] value	/args arg /next /global /local depth][	
...
			if arg: find apps request/config/root-dir [

looks like u r using a parameter as a local variable

I thought I've added a note about DO having special effect in RSP 
scripts, but I can't find any mention in the wiki.

i think there was some conversation about the overwriting 'do on 
altme, but i couldn't find it in the docs either... maybe in the 
changelog?..

The 'arg parameter is processed before that line by: 

    if args [return *do/args value arg]