Browse thread
CamlGI question
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Christophe TROESTLER <debian00@t...> |
| Subject: | Re: Common CGI interface |
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)?