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 29619BC84 for ; Tue, 26 Apr 2005 18:24:46 +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 j3QGOj85032756 for ; Tue, 26 Apr 2005 18:24:45 +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 SAA31073 for ; Tue, 26 Apr 2005 18:24:44 +0200 (MET DST) Received: from plover.csun.edu (plover.csun.edu [130.166.1.24]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j3QGOhLH032751 for ; Tue, 26 Apr 2005 18:24:44 +0200 Received: from puffin.csun.edu (puffin.csun.edu [130.166.1.21]) by plover.csun.edu (MOS 3.5.4-GR) with ESMTP id BOK80492; Tue, 26 Apr 2005 09:24:07 -0700 (PDT) Received: from [130.166.10.117] (s010n117.csun.edu [130.166.10.117]) by puffin.csun.edu (MOS 3.5.4-GR) with ESMTP id DFD13955 (AUTH eric); Tue, 26 Apr 2005 09:24:03 -0700 (PDT) In-Reply-To: <20050425.123834.56365302.debian00@tiscali.be> References: <1113940495.6248.101.camel@localhost.localdomain> <20050420.220031.69130073.debian00@tiscali.be> <1114031186.6243.48.camel@localhost.localdomain> <20050425.123834.56365302.debian00@tiscali.be> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9de43bb54de0a26c6d6fdd2fa96242e9@itkinetix.com> Content-Transfer-Encoding: 7bit Cc: caml-list@inria.fr, info@gerd-stolpmann.de, ocamlnet-devel@lists.sourceforge.net From: Eric Stokes Subject: Re: [Caml-list] Re: Common CGI interface Date: Tue, 26 Apr 2005 09:24:03 -0700 To: Christophe TROESTLER X-Mailer: Apple Mail (2.622) X-Miltered: at concorde with ID 426E6B4D.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 426E6B4B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 model:01 stdin:01 model:01 threads:01 ocamlnet:01 jserv:01 christophe:01 troestler:01 gerd:01 stolpmann:01 prng:01 reused:01 beginners: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: As far as fastcgi's process model is concerned, let me give a few more details about that. There are actually N process models for fastcgi, divided into two groups. One group is managed by the web server in an "application server" environment, and the other group is stand alone. The common case is the first group, because it is the easiest to implement, and generally works quite well. In that case, concurrency is configured at the app server level (web server). App servers implement both sequential processing, and process pools (the first being a special case of the second where p=1). The app server is generally configured to start N processes per application, and each will sequentially process requests given to it by the web server. The web server will take care of routing requests to different processes (or push it off onto the OS schedular). The serv function simply calls accept on stdin (which is a listening socket), and processes each request. All aspects of process creation and destruction are handled by the web/app server. A slight variation on this model is to create multiple threads within the same process, with each thread running a serv loop, this will maximize pseudo-parallelism within a single process, and can be a benefit for IO bound applications. CPU bound applications do not currently benefit from this model. Just within the first group of concurrency models it is possible to have the two most sought after concurrency methods in practical terms, process pool concurrency, and threaded concurrency. Because of this, very little work has been done supporting the second group, where the web server does not manage the application in any way, but instead simply connects to it as a client. However, with the current code base it is possible to use the second model, in which case you are free to implement whatever concurrency model you like. That being said, nothing is currently implemented for you. 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, and would most certainly reject out of hand any kind of silly canned attempt at a server construction kit I could provide in ocamlnet. The reason that the jserv modules provide such things, while the fastcgi modules do not is simply that those two standards decided to go in a different direction. Fastcgi tries to be just like CGI in as many ways as it can, so I find their decision to implement an application server very natural, CGI itself was perhaps one of the earliest application servers created. I admit that we have not provided extensive documentation of this in the past, and this is something I will try to remedy. However, 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. On Apr 25, 2005, at 3:38 AM, Christophe TROESTLER wrote: > 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 > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs