Rev as Web Server CGI programming language?

[Andre Garzia]

Kee,

fetch http://andregarzia.com/RevHTTP.zip

it has examples...

Andre

On Apr 18, 2007, at 1:42 PM, kee nethery wrote:

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