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

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Mittwoch, den 20.04.2005, 22:00 +0200 schrieb Christophe TROESTLER:
> On Tue, 19 Apr 2005, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> > 
> > Good idea. However, I think it is too late for such a discussion.
> > First, it already happened. [...] Ocamlnet.
> 
> Are questions welcomed?

Yes, of course. Also ideas for improvements, or just impressions.

> At the time I was not so much interested by web apps -- this is still
> not my main concern but, at times, I have to build some and I like
> both powerful and simple tools.  My experience with OCamlNet is that,
> for a newcomer, it is difficult to find ones way through it.  The
> library is impressive but, IMO, the interface could be made _simpler_
> and more orthogonal.

This is quite complicated to explain. Ocamlnet exhibits some of the
internal complexity to give "power users" more possibilities, for
example defining their own connector. Furthermore, it does not try to
hide the peculiarities of the various connector protocols. 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.

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).

> For example I am wondering why standard CGI must use [let cgi = new
> std_activation()] while FastCGI requires [Netcgi_fcgi.serv (fun cgi ->
> ...)].  Why can't the callback method be used consistently all over
> the place?  

For historical reasons, the CGI connector has a simplified entry point:

let cgi = new std_activation()

Why does this initialize for CGI? Because the argument ~env is missing,
and by default, env is tried to be taken from the process environment to
initialize for CGI. This simply means that on this level it is
implemented that CGI is the default connector.

Internally, the other connectors also create a std_activation object,
but with a certain ~env argument, making it different.

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

let cgi_serv f = f (new std_activation())

(maybe with added exception handling).

> Additional advantages are that it allows to handle
> exceptions [1], to [#finalize] automatically when the request has been
> dealt with (the user may still want to call [#finalize] manually but
> would not be required to do so) and to [#commit]/[#flush] the output.

Accepted, this would be better.

> Finally, how are we supposed to launch different threads for different
> requests [2]?

Maybe Eric can comment on this.

> 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. The command-line interface uses the
mutability of the arguments, too.

> Also, why
> not distinguish simple parameters (for which a method that returns a
> string is sufficient) and file uploads (for which one clearly wants
> more flexibility).

Because this is bullshit. It is not always a good idea to copy bad
habits of other libraries - I know that all other libraries treat simple
arguments and file arguments differently.

However, this is a difference that actually does not exist on the HTTP
level. I think it is shortsighted to artificially differ between things
that are principally the same. For example, what happens when a new HTML
feature is defined by W3C that requires a new kind of argument? E.g. a
rich text editor whose contents are transported with a new kind of
header? W3C will simply represent that argument in a form-encoded
request. The point is that OCamlnet can decode and represent all
form-encoded requests, no matter whether it is a file, a simple value,
or something completely different.

Btw, the uniform representation of arguments can already be very useful
now, for example for processing non-web requests.

> Why is there an exception [Std_environment_not_found]?  Isn't it the
> role of the library to reject requests with lack of information (and
> log them)?  Why bother the user with that?  (I don't even think one
> may want to customize the reply to such requests as they are just
> bogus.)

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

> I have a few more questions in the same vein but will stop here
> waiting for reactions before bothering everybody even more! :-)

Ok, let's see whether this discussion is fruitful.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------