On Wed, 24 Nov 1999, David Bovill wrote:
> Thanks, I think that's what I figured. I was wandering how to keep the
> "compatibility" with ".mt", perl and other cgi's (not really apple events).
> The question is more, how do I program a CGI which can easily be ported to
> Perl, or ".mt" scripts? As these ways of implementing CGI's rely heavily on
> the "Environmental variables" defined I think by the server??? then it makes
> sense to implement them by scripting stuff like:
> put the legnth of putStuffComingfromStdin into $CONTENT_LEGNTH
This would work fine on UNIX systems (except you'd have to spell it
right ;-)
> > From: Andu <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > Date: Tue, 23 Nov 1999 19:55:13 -0500
> > To: [EMAIL PROTECTED]
> > Subject: Re: More questions about mchttpd server
> >
> >> Does this go for things like REQUEST_METHOD, or QUERY_STRING, or
> >> HTTP_USER_AGENT, which would seem to only make sense when set by the server?
> >>
> > These are not exactly environment variables.
> >
> > Regards, Andu
> >
>
> OK, how do they differ? My perl book calls them environmental variables. Can
> I access and set them with "get $REQUEST_METHOD"? Would it be better to use
> globals? If mchttpd sets them, does that make them accessible to a perl or
> other program?
Environment variables are automatically global in MetaCard (you don't
need to declare them as global, the $ does that for you
automatically). The would be accessible to other programs (e.g., CGI
scripts) on UNIX systems, but on Windows (although I'm not sure why
that is and will look into this further to see if there is a way to
make this work).
> A transparent, easy to program cross-platform server, which would act as an
> easy entry to learning and implementing a dynamic web site - would be a kind
> of mission statement. It would seem to make sense to implement environmental
> variables as it would seem that most CGI's need them (even if they are
> implemented as Andu has sugested), and doing it this way would:
>
> 1) facilitate eventual porting to other cgi environments (ie if your
> aim was rapid prototyping), and
> 2) teach cgi principles (if your aim is eventually to learn perl etc).
This is a pretty important design decision and so I think we should
consider it carefully. While it's true that using environment
variables would make it easy to replace a built-in handler with an
external CGI program on UNIX, there are problems with this approach.
The most obvious one being that it won't work on Mac or Windows. It
probably could be made to work on Windows, but can never work on Mac
and indeed wouldn't make any sense to a Mac-based developer.
Another issue is that enviroment variables are global, which means
that if you try to have multiple handlers running at the same time,
you're going to have conflicts where changing those variables for one
will screw up the other. While the script execution system is
currently single threaded, there are a lot of things that can cause a
break in one handler that will allow other other handlers to execute
(it's kind of like MacOSs "cooperative multitasking" design). And we
can't rule out the possibility that multithreading will be supported
in the script execution system in the future.
Finally, setting environment variables is about 20 times slower than
setting regular variables (the entire environment must be copied each
time you set any of the variables). While this is a drop in the
bucket compared with the overhead of starting up a separate process as
normal CGI systems do, it's still a hit we shouldn't take without a
really good reason.
Another method to consider is to pass all of the "environment
variables" as a parameter array. This is pretty much equivalent to
the AppleEvent system used on Macs, but much simpler (and faster).
Here's something that would do the same thing as the echo.mt script,
except run as a handler within mchttpd:
on mouseUp
put "GET" into cgiParams["REQUEST_METHOD"]
put "HTTP/1.0" into cgiParams["SERVER_PROTOCOL"]
mycgi cgiParams
end mouseUp
on mycgi myparams
repeat for each line l in keys(myparams)
put l && "=" && myparams[l] & cr after it
end repeat
put it
end mycgi
As shown above, we could use the standard *names* for the various
parameters if this is deemed desirable. And if the above looks like
greek to you, you should get the 2.3 beta and play around with this
script in it. Setting and passing arrays around like this is an
important technique to understand as it greatly simplifies some kinds
of problems.
> I like this idea. The problem I am having with it at the moment is that
> according to a recent post adding a new cgi will only be possible in the
> full development environment. If I am right this is because setting the
> script length to greater than 10 lines will not be possible in the starter
> kit. The only solution is to "do" 1 line at a time, or limit cgi's to 10
> lines!
*Adding* a new CGI of any size would no problem. Developing one of
non-trivial complexity without a license could be difficult, though.
Regards,
Scott
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
