Rev as Web Server CGI programming language?

[kee nethery]

Am trying to cut through the marketing chatter and understand the  
limitations of using RunRev for CGI work. Here is what I think I  
know, I'd appreciate corrections.

Andre Garzia's RevHTTP stack is a really nice way to build a web  
based application in RunRev. You can use the debugger and you can  
store data in stacks and you can use the various installer apps to  
keep the web stack updated. It is single threaded such that when one  
connection comes in, no other connections can be processed until the  
current connection is done.
Stack based - yes (build and troubleshoot on your desktop and copy to  
server)
Apache server "cgi" - no
Built-in web server - yes (IT folks are uncomfortable with standalone  
web servers)
Debuggable - yes (you can have a connection go through the debugger  
on the server)
Negligible launch and tear down overhead for each connection - yes  
(launch once and it is always running)
Multiple connections - no
Multiple simultaneously processing connections - no
Global Variables that are global for all connections to the web  
service - yes (one stack)
Global Variables that are specific to a single connection - yes (each  
connection can get setup with the initial connection globals)

File based script version of Jacqueline Landman Gay's tutorial uses  
the traditional Apache CGI structure and RunRev as the backend  
process and as such, a new instance of the script gets created for  
each incoming connection. This is good for simultaneous multiple  
connections, but the text script version prevents using the RunRev  
debugger.
Stack based - no
Apache server "cgi" - yes (IT folks are comfortable managing Apache  
installations, it's a known knowledge set)
Built-in web server - no
Debuggable - no
Negligible launch and tear down overhead for each connection - no  
(each script instance is fast to handle but with hundreds of  
connections per second, launch and tear down will become an issue)
Multiple connections - yes (each connection spawns a new instance of  
the script)
Multiple simultaneously processing connections - yes (the separate  
instances have no connections with each other and Apache handles the  
simultaneous processing)
Global Variables that are global for all connections to the web  
service - yes (when stored in a common text file read at startup)
Global Variables that are specific to a single connection - yes (the  
script can have setup variables at launch)

The stack based version of Jacqueline Landman Gay's tutorial uses a  
simple file based script to execute scripts in stacks. This uses the  
traditional Apache CGI structure where a new incoming connection  
spawns a new instance of the script and that script interacts with a  
stack. This is where I am unsure. If the processing happens in stack  
scripts, how is contention handled when 100 script instances want to  
utilize the same stack? Do the scripts single thread one at a time to  
the stack? How is data stored in the stack by one connection handled  
by all the other connections?
Stack based - yes
Apache server "cgi" - yes
Built-in web server - no
Debuggable - yes
Negligible launch and tear down overhead for each connection - no
Multiple connections - yes
Multiple simultaneously processing connections - no
Global Variables that are global for all connections to the web  
service - yes (stored in "the stack")
Global Variables that are specific to a single connection - yes  
(because "the stack" can only be used by one connection at a time and  
the connection can reset the connection variables)


What I'd like is the following. I want to build and debug using all  
the stack editing tools. I'm OK with single threading while I am  
debugging. But once I've debugged it, I want, for example, 100  
simultaneous connections each running their copy of "the stack", with  
each stack having access to shared data (Globals), but containing  
it's own data about it's connection (connection specific globals),  
and for these connections to stay up and be available for the next  
connection without the overhead of launching a fresh copy of the  
script or of the stack (high performance), oh and while I'm at it, if  
a stack is 2Mb in size and the data that I add to it is another 2Mb  
in size, can the memory footprint for additional connections be just  
the additional RAM needed for another set of data and not for another  
copy of the stack? Is there a way to get this using RunRev?
Stack based - yes
Apache server "cgi" - yes
Built-in web server - no
Debuggable - yes
Negligible launch and tear down overhead for each connection - yes
Multiple connections - yes
Multiple simultaneously processing connections - yes
Global Variables that are global for all connections to the web  
service - yes (stored in "the stack")
Global Variables that are specific to a single connection - yes  
(initialized by the CGI script before being fed to "the stack")


Is anyone doing a combo of Jacqueline's file and stack methods? Using  
the stack method to debug and keeping everything in the stack script  
and avoiding the commands that don't work when in a text file.


Kee Nethery