Re: [Caml-list] Re: Common CGI interface

[Eric Stokes <gremlin@itkinetix.com>]

	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 <info@gerd-stolpmann.de> 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