From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id ECA17BC84 for ; Wed, 20 Apr 2005 23:06:30 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j3KL6Upj025093 for ; Wed, 20 Apr 2005 23:06:30 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA30373 for ; Wed, 20 Apr 2005 23:06:29 +0200 (MET DST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j3KL6TZ0001019 for ; Wed, 20 Apr 2005 23:06:29 +0200 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DOMOz-0006Gx-00; Wed, 20 Apr 2005 23:06:29 +0200 Received: from [84.167.141.50] (helo=gate.lan.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1DOMOy-000150-00; Wed, 20 Apr 2005 23:06:28 +0200 Received: from flakew.lan.gerd-stolpmann.de (flakew.lan.gerd-stolpmann.de [192.168.0.32]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id C9AF8C10A; Wed, 20 Apr 2005 23:06:27 +0200 (CEST) Subject: Re: [Caml-list] Re: Common CGI interface From: Gerd Stolpmann To: Christophe TROESTLER Cc: "O'Caml Mailing List" , ocamlnet-devel@lists.sourceforge.net In-Reply-To: <20050420.220031.69130073.debian00@tiscali.be> References: <20050419084526.Q20372@bowser.eecs.harvard.edu> <20050419.210334.63756712.debian00@tiscali.be> <1113940495.6248.101.camel@localhost.localdomain> <20050420.220031.69130073.debian00@tiscali.be> Content-Type: text/plain Date: Wed, 20 Apr 2005 23:06:26 +0200 Message-Id: <1114031186.6243.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at nez-perce with ID 4266C456.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4266C455.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 christophe:01 troestler:01 gerd:01 stolpmann:01 ocamlnet:01 ocamlnet:01 orthogonal:01 beginners:01 threads:01 debugging:01 command-line:01 viktoriastr:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: Am Mittwoch, den 20.04.2005, 22:00 +0200 schrieb Christophe TROESTLER: > On Tue, 19 Apr 2005, Gerd Stolpmann 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 ------------------------------------------------------------