>> What are the concrete advantages of using this engine over using Metacard to
>> develop CGI solutions?
>
> Not sure I follow this: the only way to do CGI with the full,
> graphical, version of MetaCard is under MacOS, where CGI is done with
> AppleEvents.
??? What was I doing when I used the full graphical version/engine for MC on
Linux as the CGI engine for Apache? I was sure I got this working -:) In
other words presuming this wasn't a case of false memory syndrome brought
about by an over enthusiatic adoption of the incomprehensible power of
Metacard...
How does the MC/Linux/Apache solution differ from the console version CGI
solutions performance/implementation wise?
Thanks in advance...
> But this engine is only for the UNIX part of Mac OS X
> (aka Darwin) which doesn't support AppleEvents and instead uses stdio
> (Standard I/O) for communication between the HTTP server and CGI
> application. These things are *very* different from anything you may
> have done with the graphical version of MetaCard. There are some
> examples on the MetaCard WWW site.
>
>> 1) Memory?
>
> Should be considerably less than a full graphical application.
>
>> 2) Speed?
>
> Should be much faster than a graphical application, or any comparable
> MacOS application because of UNIX's better architecture.
>
>> 3) Script limits
>
> There are none for MetaTalk scripts like this. This is true for all
> of the UNIX engines and the console-mode Win32 engine too.
>
>> Will the engine run Metacard stacks direct in "console-mode"? Does this
>> require saving the stack as a standalone with this new engine?
>
> You can refer to stacks to get data out of them, but they won't be
> visible anywhere when you "go" to them. You can't build standalones
> with .mt scripts.
> Regards,
> Scott
>
And in retrospect -:)
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
