Rev as Web Server CGI programming language?

[kee nethery]

Andre appears to do what I was pondering, write and debug using the  
stack based web server, and then deploy under apache in a text file.  
My plan is to try to document the development process so that I'll be  
able to remember how to use it months from now. When I get that  
documented I'll pass it back to the list. Looks like this is a good  
95% of the solution I desire. And that should be good enough for now.

Kee


On Apr 18, 2007, at 7:42 AM, Phil Davis wrote:

> 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
> _______________________________________________
> 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