Re: [MacPerl-Porters] MacPerl CGI runtime?

[David Steffen <steffen@biomedcomp.com>]

Vicki Brown said:

>I asked Chris the other day if it would be possible to make a Runtime
>version of the MacPerl CGI extension...
>
>He said it should be (although he didn't volunteer to create it).
>
>While I admit that a Runtime script is BIG, wouldn't this provide a
>temporary fix for folks who want to run  more than one CGI at a time?
>
>Unfortunately, it still doesn't solve the problem of simultaneous users
>trying to run the _same_ CGI script...

Every time this topic comes up, I curse myself for not documenting my
experimentation on this point.  Because I didn't, the following is from my
50 year old, unreliable memory.  This really should go into the FAQ, as
Perl is *THE* language for cgi's, whereas MacPerl in its current form
requires care if used for CGI's.  (This is the fault of MacOS, not MacPerl,
AFAIK.)

If you have a Mac dedicated as a web server, and if you are running
WebSTAR, and if you have two CGI's ("I call these two CGI's CGI1 and CGI2")
and if you request CGI1, and then while it is executing, request CGI2, CGI1
will finish, produce output, and then CGI2 will begin, execute, and then
produce output.  (Exactly the same thing happens in the case of CGI1 and
CGI1.)  In most cases this is just fine; most CGI's run pretty quickly and
so waiting for the first one to finish before the second one starts is no
problem.  In this case, there is no need for a standalone CGI.

Why one would want a standalone CGI:

If you DON'T dedicate the Mac as a webserver; if you try to do work on it
at the same time (which I am doing as I type), programming in MacPerl will
be disrupted by calls to a MacPerl CGI.  A standalone CGI would solve this.

Another problem not (completely) solved by a standalone CGI:

On the Mac (at least with WebSTAR), using a suffix of .acgi instead of .cgi
signals to the Web server that the CGI can handle multiple hits.  With an
.acgi written in AppleScript, this buys you nothing, AFAIK, as the two
invocations are executed serially just as if they were .cgi's.  With
Frontier, the two scripts can be executed "simultaneously".

In MacPerl, use of the .acgi suffix signals that the CGI is capable of
"server push"; that data is presented to the client as it is returned
rather than all at once in a big lump.  This is important if you are
presenting a lot of data very slowly; without this ability, the client may
time out (or the user give up) before all the data is ready.
Unfortunately, this suffix also tells WebSTAR that your application can
handle multiple hits (= multiple threads?), which MacPerl can't; at best
overlapping hits are lost, at worst, your Mac crashes.  Thus, if you had
standalone CGI's, you could overlap calls to ACGI1 and ACGI2, but not to
ACGI1 and ACGI1.  (Is this what you were referring to, Vicki?)  I have
stared at the source code for the MacPerl CGI glue, wondering what its
lifecycle was like.  I wondered if it could be modified to look for more
input from WebSTAR after sending off its message to MacPerl, in which case
overlapping hits to ACGI1 and ACGI1 would work as long as there was enough
time between them for the CGI glue to get its message off to MacPerl; not
perfect but probably good enough for government work.

I have even less hair than when I started worrying about this a couple
years ago, so any corrections or other comments will be gratefully received.

-David Steffen-

David Steffen, Ph.D.
President, Biomedical Computing, Inc. <http://www.biomedcomp.com/>
Phone: (713) 610-9770 FAX: (713) 610-9769 E-mail: steffen@biomedcomp.com



==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-porters-request@macperl.org