Re: Common CGI interface

[Christophe TROESTLER <debian00@tiscali.be>]

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?

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.

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?  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.
Finally, how are we supposed to launch different threads for different
requests [2]?

About arguments: is the mutability of arguments useful?  This makes
the whole interface more complex for a purpose I can't see.  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).

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

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

Regards,
ChriS

---
[1] I believe the library should just log them and process the next
request.  Moreover [Exit] should probably be treated specially as a
way to terminate the script early (say after an error message).

[2] I read the reply of Eric Stokes but I do not understand it: are
the various threads going to share the same socket??  And what about
if requests are multiplexed (this is not currently supported by Apache
but may be eventually with the new threaded Apache and is definitely
supported by other web servers)?