[Prev][Next][Index][Thread]
Re: A Thought on CGI & CL-HTTP
JCMA@ai.mit.edu (John C. Mallery) wrote...
>Most applications of CGI scripts in conventional WWW applications are
>light weight. They are fired up and go away on each invocation.
>Thus, the main event is an HTTP server doing various little tasks as
>requests come in.
My Mac experience with WebSTAR and CGIs (such as NetCloak/NetForms and
several AppleScripts) is that load & quit can be controlled to suit request
frequency, response timing, and memory management by setting options for
"noquit" or "quit after time duration X inactive".
What do you mean by "light weight"?
Certainly WebSTAR can only invoke a single CGI per user request, the
actions are rigidly limited to what can be controlled by the transaction
data, scripts are slow (however compiled C modules are fast)... but CGI
access to something like a 4D database or AppleSearch is valuable and might
at least be called "medium weight".
Also, CGIs provide an "open" architecture for plugging in modules from
multiple developers.
>So, the bottom line is that CL-HTTP is out there to help people explore the
>space of more sophisticated Web applications that may include elements of
>Artificial Intelligence.
>
>One of the more important areas to explore is turning the Web into
>a worldwide knowledge representation.
I am interested in CL-HTTP because of the potential to allow complex,
flexible, and adaptive Web access to the "worldwide knowledge
representation" you mention. However, the ability for mcl/CL-HTTP
interface to standardized, optimized, modules is also important. With
this, the Web Server would be formed through a "society of mind-uals", with
CGIs being the specialized organs and CL-HTTP providing the framework for
higher-level functions.
>Beyond escaping the prison of conventional CGIs, a key feature of CL-HTTP
>is that the Lisp programmer has access to the entire server, and can
>customize >or extend it as desired for any application. On Lisp Machines,
>this
>arrangement extends throughout the operating system. On conventional
>architectures, the foreign function interface becomes important when
>there is a need to reach beyond the lisp environment.
Would it be beneficial for mcl/CL-HTTP implementation do define a standard
"foreign function interface" analogy to the CGI standard to establish an
"open" environment for the community of developers?
John Hanna