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