Getting into some meat here. Thanks, it is really helpful.
> From: Scott Raney <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Wed, 24 Nov 1999 10:34:23 -0700 (MST)
> To: [EMAIL PROTECTED]
> Subject: Re: More questions about mchttpd server
>
> On Wed, 24 Nov 1999, David Bovill wrote:
>
>> 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.
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
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).
>
> 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.
This true for global variables?
>
> 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.
OK, this may be a reasonable way forward (though I don't know Greek -:)
>
>> 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.
>
> ********************************************************
> Scott Raney [EMAIL PROTECTED] http://www.metacard.com
> MetaCard: You know, there's an easier way to do that...
>
