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