Re: WWWally pt.2

> From: "WALLYWORLD" <ran...@[EMAIL PROTECTED]
>
> i actually don't know the best way to combine C executables with
> the CGI framework.

Why is that an im****tant question. Didn't you ever hear of "good enough"?

What sort of C executables do you feel would be needed within a CGI
framework? Are you talking about the standard types of utilities
such as occur on Unix? Or are you talking about custom C
applications per the specific CGI application?

The standard utilities basically take in one dataset and produce
another, possibly refering to another dataset (these datasets
typically being flat text files). These are easy to incor****ate
into a higher-level script, regardless of whether that script is
written in sh (or csh etc.) or perl or lisp or PHP etc. If
application-specific executables are likewise written in the same
style, they should likewise be easily incor****ated into the
toplevel script.

But this all begs the question whether there's any need for custom
C applications. If the main CGI application is written in lisp or
java, there might not be any need whatsoever to call any C
sub-application.

> I though that the answer was to use an HTML page with an ActiveX
> connection to the executable (through the operating system) using
> those CLSID  numbers.

Why is that needed? Why not just run the executable as a
sub-process under lisp, with stdin and stdout piped through the
toplevel application? The toplevel calls FORMAT to transmit
commands to the sub-process, and uses READ-LINE followed by some
simple parser to receive results back from the sub-process.

> The executable would first be registered with the operating
> system as a component.

With stdio sub-applications, all you need to invoke it is the
directory-path and filename, and with shell variable $PATH set up
properly you can omit the directory-path. Why bother with a more
complicated system of registering components?