On Wed, 24 Nov 1999, David Bovill wrote:
> > 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.
>
> The bit that makes sense to a Mac developer is the following sort of code
> that I could program in a custom metacard CGI that I want o add to the
> mchttpd server (having the option to use it also for .mt scripts on UNIX
> servers):
>
> if $USER_AGENT contains "MSIE" then
> doSomething
> else
> dosomethingelse
> end if
Maybe. Assuming the $ stuff doesn't throw them. You don't do this
kind of thing in any other context (least of all in Mac CGIs).
> This is exactly the sort of thing I'd need to do if I were to write a perl
> cgi (and it should work for .mt script exports). So I figure the mchttpd
> server should set these automatically on all platforms (even if they are
> only available to external processes on Unix).
Can you write CGIs on Mac with Perl? If so I'd imagine it *would*
look like the above because you have to use $ in front of *all*
variable references in Perl.
> > 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.
>
> This true for global variables?
Nope, just for environment variables (those globals with names that
start with $).
> >> 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
>
> How can I set the script of a Metacard stack to greater than 10 lines in the
> starter kit. Didn't think this was possible from a script.
It isn't, nor would it typically be in a running mchttpd session
(which shouldn't need to ever do this). But if you've got a CGI that
someone with the full license wrote, you could plug it in to your
mchttpd server by just adding the name of that stack to a list of
files that the server "starts using" when you start it up. Each of
those stacks would have one handler (or at least one main handler
callable from mchttpd) that the browser would ask for a result from.
Regards,
Scott
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
