Where Rev could be going...
revolutionary.dan at gmail.com
Sat Nov 18 15:19:11 EST 2006
Andre is much more knowledgeable and deeply experienced in this subject than
I, and I suspect he'll jump in here as well, but FWIW, here's my take.
It is perfectly possible to use Rev as a CGI platform. I have successfully
coded CGIs of moderate complexity on both Linux and OS X. Once you get over
the same kinds of niggling details that plague CGI as a technology
regardless of the implementation language, these CGIs work just fine.
However, the inability to thread in Rev effectively makes the use of Rev for
CGI applications pretty limited as a practical matter. Each execution of the
CGI is effectively blocking in nature. (I'm over-simplifying a bit here, I
know, but I think this is the primary concern in broad terms.) Each
invocation of the CGI waits for previous invocations to terminate. In a
low-usage environment, the wait is acceptable and depending on what the CGI
is actually doing, it can be unnoticeble. But to use a CGI in a production
server environment where the amount of load is unpredictable or known to be
large, Rev is a non-starter.
Pierre Sahores, with his insead technology, has found some very clever and
obtuse ways around the limitations of Rev as a CGI and appears to have had
some great success with his approach. I have never had a project on which I
could try insead, so all I can go by is the fact that Pierre is bright and
one of the better scripters I know.
On 11/17/06, Bernard Devlin <revolution at knowledgeworks.plus.com> wrote:
> Maybe Dan or Andre could comment on what they think about the 4th
> item? I seem to remember some posts a few months ago where they were
> expressing some exasperation with Rev CGIs. Was the principle
> limitation with Rev CGI to do with threading and scalability?
Dan Shafer, Information Product Consultant and Author
Get my book, "Revolution: Software at the Speed of Thought"
More information about the Use-livecode