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 0C55CBCAB for ; Fri, 6 May 2005 22:15:01 +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 j46KF0TK013069 for ; Fri, 6 May 2005 22:15:00 +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 WAA08954 for ; Fri, 6 May 2005 22:14:59 +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 j46KExQL013064 for ; Fri, 6 May 2005 22:14:59 +0200 Received: from poincare (Debian-exim@poincare.swapping.umh.ac.be [10.102.100.35]) by hedwig1.umh.ac.be (8.13.1/8.13.1) with ESMTP id j46KFN9W385118; Fri, 6 May 2005 22:15:29 +0200 Received: from localhost ([127.0.0.1] ident=trch) by poincare with esmtp (Exim 4.50) id 1DU9Dj-0005Yp-41; Fri, 06 May 2005 22:14:47 +0200 Date: Fri, 06 May 2005 22:14:46 +0200 (CEST) Message-Id: <20050506.221446.48495978.Christophe.Troestler@umh.ac.be> To: Eric Stokes Cc: caml-list@inria.fr, info@gerd-stolpmann.de, ocamlnet-devel@lists.sourceforge.net Subject: Re: [Caml-list] Re: Common CGI interface From: Christophe TROESTLER In-Reply-To: <9de43bb54de0a26c6d6fdd2fa96242e9@itkinetix.com> References: <1114031186.6243.48.camel@localhost.localdomain> <20050425.123834.56365302.debian00@tiscali.be> <9de43bb54de0a26c6d6fdd2fa96242e9@itkinetix.com> Organization: Universite de Mons-Hainaut (http://math.umh.ac.be/an/) X-Spook: Marxist JFK lock picking supercomputer industrial intelligence electronic surveillance Soviet Waco, Texas Centro quarter 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 427BD044.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 427BD043.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 christophe:01 troestler:01 christophe:01 troestler:01 umh:01 minor:01 model:01 threads:01 threads:01 ocaml:01 iirc:01 ocamlnet:01 jserv:01 jserv: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: Hi! First of all, let me say that the code for the FCGI connector will need to be changed! Indeed, Netcgi prides itself on not having the same limitations as the other libraries, in particular the Sys.max_string_length limit. But the FCGI module very much has it as the entire input for a request is accumulated into a string! I also believe the FCGI connector should support multiplexing of requests since it is part of the spec. Also, as a minor remark, the object [fcgi_out_channel] does not protect against [#output ""] unwittingly closing the channel. On Tue, 26 Apr 2005, Eric Stokes wrote: > > As far as fastcgi's process model is concerned [...] managed by the > web server [...] stand alone. The common case is the first group > [...] A slight variation [...] create multiple threads within the > same process, with each thread running a serv loop [...] Ok -- several threads can share a given socket, even without a mutex. > second group [...] My view is that if you are writing an application > for which the concurrency models provided by the web server are not > sufficient then you are more than likely working on a very big > project, Let me strongly disagree with that. For example, where I work, they will not be much keen to let me run a script on the web server (because of security concerns and space reasons). Moreover, OCaml support for AIX has been dropped recently IIRC so that would not be possible anyway. > and would most certainly reject out of hand any kind of silly canned > attempt at a server construction kit I could provide in ocamlnet. Is this how you would characterize what JSERV offers? ;) In any case, if the way JSERV handle concurrency models is good enough, then I see no reason FCGI does not support that as well... The ideal situation would be that a concurrency module be built on top of a set of functions (through, say, a functor) for both FCGI and AJP. > there is a lot of good documentation on the workings of fastcgi, and > on building fastcgi applications in general. We try to implement a > fastcgi connector that is close enough to the standard that that > documentation is useful. Yes and no. The interface is fairly different from the ones in e.g. C++ or Perl, so some doc on how to use it for multiprocesses / multithreads is welcome. Regards, ChriS