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 16E97BC48 for ; Mon, 25 Apr 2005 12:39:28 +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 j3PAdRUa013673 for ; Mon, 25 Apr 2005 12:39:27 +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 MAA18102 for ; Mon, 25 Apr 2005 12:39:27 +0200 (MET DST) Received: from hedwig1.umh.ac.be (hedwig2.umh.ac.be [193.190.193.73]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j3PAdQhi004321 for ; Mon, 25 Apr 2005 12:39:26 +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 j3PAdb5R778266; Mon, 25 Apr 2005 12:39:44 +0200 Received: from localhost ([127.0.0.1] ident=trch) by poincare with esmtp (Exim 4.50) id 1DQ0z4-00013v-UM; Mon, 25 Apr 2005 12:38:34 +0200 Date: Mon, 25 Apr 2005 12:38:34 +0200 (CEST) Message-Id: <20050425.123834.56365302.debian00@tiscali.be> To: info@gerd-stolpmann.de Cc: caml-list@inria.fr, ocamlnet-devel@lists.sourceforge.net Subject: Re: [Caml-list] Re: Common CGI interface From: Christophe TROESTLER In-Reply-To: <1114031186.6243.48.camel@localhost.localdomain> References: <1113940495.6248.101.camel@localhost.localdomain> <20050420.220031.69130073.debian00@tiscali.be> <1114031186.6243.48.camel@localhost.localdomain> Organization: Universite de Mons-Hainaut (http://math.umh.ac.be/an/) X-Spook: blackjack Compsec Geraldton basement FTS2000 domestic disruption Mantis Manfurov USCODE propaganda 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 nez-perce with ID 426CC8DF.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 426CC8DE.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 christophe:01 troestler:01 gerd:01 stolpmann:01 prng:01 reused:01 beginners:01 jserv:01 val:01 sockaddr:01 rework:01 conceptually:01 stderr:01 stderr: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 Wed, 20 Apr 2005, Gerd Stolpmann wrote: > > defining their own connector. I understand one needs to do so to extend the library but can you name other situations? My feeling is that CGI, FCGI, AJP, and test are the more used ones and that a custom connector is seldom needed... so shouldn't the standard connectors share a common standard (of course with a few peculiarities to each) while the function(s) to create new ones are grouped into a separate module. The prng* functions should be in the main module -- an additional [random_sessionid] function (generating e.g. 128 bits random strings) could be useful. > Furthermore, it does not try to hide the peculiarities of the > various connector protocols. The purpose of the various connectors being the same, I believe they should share a common interface whenever possible. It is needlessly inconvenient to have to learn different interfaces for a given concept. Also, whenever possible, I believe names from the standard library should be reused (e.g. establish_server). > 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. It is good to be able to choose. For FCGI however, I was expecting some comments of Eric to understand better how it works (including multiplexing). > 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). I am afraid that I am not sure to fully grasp which kind of modularity you have in mind -- certainly because of my lack of experience in web devel. For example, I do not understand why [Netcgi_jserv.server_init] is not just included in [server_loop]. Another reason modularity is good for it multithreading (or multiple processes). But there are other ways to handle that than to split into many functions. For example, on can imagine val establish_server : ?max_conns:int -> ... -> ?fork:((connection -> unit) -> connection -> unit) -> (connection -> unit) -> Unix.sockaddr -> unit (?fork can create a process or a thread). This makes it possible to wrap the function handling the connection (connection -> unit) so that exceptions it raises are dealt with appropriately -- thus for example it seems possible to get rid of the care the user must exercise with [Signal_shutdown]... May you explain situations for which a [establish_server] / [handle_request] modularity is not enough? > If we added the callback method for CGI, it would be simply I am not suggesting to simply _add_ one (that would just make the whole interface more confusing) but to rework the interface so that * all connectors are treated equally (e.g. CGI is noting special w.r.t. other, conceptually) and the modularity is handled the same way for all of them (short of optional arguments). * a separate module possesses the material to extend netcgi, e.g. to create specially tailored connectors. Another thing that seems to be lacking is a uniform way to write in the server log. For CGI it is stderr, FCGI uses special "channel" (not stderr),... This is important e.g. to log nonfatal errors. > > 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. May you explain how? Is it useful to modify the value of a param inside a request handling function, with global effect (i.e. not just for the function scope)? Setting parameters before handling the request is a different matter -- a powerful "test" mode can certainly do this without mutability (exposed). > The command-line interface uses the mutability of the arguments, Well, it is fine with me that the function creating the environment can modify it. What I am objecting is that [cgi_activation] offers functions to mutate them. > > [Std_environment_not_found] > See above: CGI is the default connector, and this exception is raised > when the default does not apply. But then, if you do not treat CGI in a special way (i.e. have distinct CGI and test connectors) it is not needed. In fact, it is not clear to me why it is good to have [std_environment] and [test_environment] in the interface as, as far as I can tell, they will just be used to implement the associated connectors (i.e. what this modularity brings you?). [custom_environment] is fine and should be put in the "extension" module. Regards, ChriS