From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 0D507BC84 for ; Wed, 20 Apr 2005 22:01:22 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j3KK1LI8025023 for ; Wed, 20 Apr 2005 22:01:21 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA27695 for ; Wed, 20 Apr 2005 22:01:21 +0200 (MET DST) Received: from hedwig1.umh.ac.be (hedwig2.umh.ac.be [193.190.193.73]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j3KK1KtN018435 for ; Wed, 20 Apr 2005 22:01:20 +0200 Received: from poincare (mathwifi.swapping.umh.ac.be [10.102.100.195]) by hedwig1.umh.ac.be (8.13.1/8.13.1) with ESMTP id j3KK1gkM1576972; Wed, 20 Apr 2005 22:01:45 +0200 Received: from localhost ([127.0.0.1] ident=trch) by poincare with esmtp (Exim 4.50) id 1DOLNO-0005dX-PN; Wed, 20 Apr 2005 22:00:46 +0200 Date: Wed, 20 Apr 2005 22:00:31 +0200 (CEST) Message-Id: <20050420.220031.69130073.debian00@tiscali.be> To: "O'Caml Mailing List" Cc: ocamlnet-devel@lists.sourceforge.net Subject: Re: Common CGI interface From: Christophe TROESTLER In-Reply-To: <1113940495.6248.101.camel@localhost.localdomain> References: <20050419084526.Q20372@bowser.eecs.harvard.edu> <20050419.210334.63756712.debian00@tiscali.be> <1113940495.6248.101.camel@localhost.localdomain> Organization: Universite de Mons-Hainaut (http://math.umh.ac.be/an/) X-Spook: chameleon man KGB ISEC embassy Legion of Doom DES warfare IRA AK-47 Blowpipe X-Blessing: Om Ah Hum Vajra Guru Pema Siddhi Hum X-Operating-System: GNU/Linux (http://www.linux.org/) X-Mailer-URL: http://www.mew.org/ X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-Miltered: at concorde with ID 4266B511.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4266B510.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; christophe:01 troestler:01 gerd:01 stolpmann:01 ocamlnet:01 ocamlnet:01 orthogonal:01 threads:01 terminate:01 threads:01 ...:98 serv:98 ...:98 wrote:01 exception:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=disabled version=3.0.2 X-Spam-Level: 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? 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)?