Re: [Caml-list] Re: Common CGI interface

[Christophe TROESTLER <debian00@tiscali.be>]

On Wed, 20 Apr 2005, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 
> defining their own connector.

I understand one needs to do so to extend the library but can you name
other situations?  My feeling is that CGI, FCGI, AJP, and test are the
more used ones and that a custom connector is seldom needed...  so
shouldn't the standard connectors share a common standard (of course
with a few peculiarities to each) while the function(s) to create new
ones are grouped into a separate module.  The prng* functions should
be in the main module -- an additional [random_sessionid] function
(generating e.g. 128 bits random strings) could be useful.

> Furthermore, it does not try to hide the peculiarities of the
> various connector protocols.

The purpose of the various connectors being the same, I believe they
should share a common interface whenever possible.  It is needlessly
inconvenient to have to learn different interfaces for a given
concept.  Also, whenever possible, I believe names from the standard
library should be reused (e.g. establish_server).

> One sees that every CGI request is performed by a new process, and
> for FastCGI and AJP it is not hidden whether multi-processing or
> multi-threading is used to parallelize requests.

It is good to be able to choose.  For FCGI however, I was expecting
some comments of Eric to understand better how it works (including
multiplexing).

> Of course, this is confusing for beginners, but I don't really see
> how to improve this without giving up modularity (i.e. every
> connector has its own entry point).

I am afraid that I am not sure to fully grasp which kind of modularity
you have in mind -- certainly because of my lack of experience in web
devel.  For example, I do not understand why
[Netcgi_jserv.server_init] is not just included in [server_loop].
Another reason modularity is good for it multithreading (or multiple
processes).  But there are other ways to handle that than to split
into many functions.  For example, on can imagine

  val establish_server : ?max_conns:int -> ... ->
    ?fork:((connection -> unit) -> connection -> unit) ->
    (connection -> unit) -> Unix.sockaddr -> unit

(?fork can create a process or a thread).  This makes it possible to
wrap the function handling the connection (connection -> unit) so that
exceptions it raises are dealt with appropriately -- thus for example
it seems possible to get rid of the care the user must exercise with
[Signal_shutdown]...

May you explain situations for which a [establish_server] /
[handle_request] modularity is not enough?

> If we added the callback method for CGI, it would be simply

I am not suggesting to simply _add_ one (that would just make the
whole interface more confusing) but to rework the interface so that

* all connectors are treated equally (e.g. CGI is noting special
  w.r.t. other, conceptually) and the modularity is handled the same
  way for all of them (short of optional arguments).

* a separate module possesses the material to extend netcgi, e.g. to
  create specially tailored connectors.

Another thing that seems to be lacking is a uniform way to write in
the server log.  For CGI it is stderr, FCGI uses special "channel"
(not stderr),...  This is important e.g. to log nonfatal errors.

> > About arguments: is the mutability of arguments useful?  This makes
> > the whole interface more complex for a purpose I can't see.  
> 
> For example, to help for debugging.

May you explain how?  Is it useful to modify the value of a param
inside a request handling function, with global effect (i.e. not just
for the function scope)?  Setting parameters before handling the
request is a different matter -- a powerful "test" mode can certainly
do this without mutability (exposed).

> The command-line interface uses the mutability of the arguments,

Well, it is fine with me that the function creating the environment
can modify it.  What I am objecting is that [cgi_activation] offers
functions to mutate them.

> > [Std_environment_not_found]
> See above: CGI is the default connector, and this exception is raised
> when the default does not apply.

But then, if you do not treat CGI in a special way (i.e. have distinct
CGI and test connectors) it is not needed.  In fact, it is not clear
to me why it is good to have [std_environment] and [test_environment]
in the interface as, as far as I can tell, they will just be used to
implement the associated connectors (i.e. what this modularity brings
you?).  [custom_environment] is fine and should be put in the
"extension" module.

Regards,
ChriS