Rev as Web Server CGI programming language?

[Andre Garzia]

Kee,

What I do here is this, I use the latest RevHTTP to build  
applications such as the ones on Jacques stack based tutorial. I  
debug and make sure it works in RevHTTP but I deploy on apache. The  
latest RevHTTP is able to run revolution CGI apps, no matter if they  
are file based or stack based. So I get the best of both worlds, easy  
debugging and testing from inside Rev and powerful serving from  
Apache. The trick is done by using my EasyCGI libraries. When run on  
RevHTTP, those library calls are overriden (can't. spell. english.)  
by RevHTTP so it all works together.

The EasyCGI libraries make lots of things easy for they have  
functions for: communicating with the browser, session handling, rpc.

The demos in RevHTTP package shows how to use everything. Nothing  
beats using breakpoints on web applications.

Cheers
andre


On Apr 18, 2007, at 9:47 AM, 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