Rev as Web Server CGI programming language?

[Phil Davis]

Hi Kee -

Great blueprint! Thanks.

Phil Davis


kee nethery wrote:
> 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
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>