Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
CamlGI question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-04-18 (14:32)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] CamlGI question
Am Montag, den 18.04.2005, 15:49 +0200 schrieb Alex Baretta:
> Robert Roessler wrote:
> > I am not able to shed any light on the CamlGI question... OTOH, the 
> > announcement from Gerd Stolpmann a few days ago regarding Ocamlnet 1.0 
> > may be of interest, given that it includes "a mature implementation of 
> > the CGI protocol" and "an implementation of the FastCGI protocol".
> It is worth noting that Baretta DE&IT has commissioned a full 
> implementation of the HTTP/1.1 protocol from Gerd. The HTTP library will 
> be based on Ocamlnet and will export more or less the same API as the 
> Netcgi module. We chose this approach rather than FastCGI because the 
> FastCGI project seems dead and did not look like a viable solution for 
> our Xcaml application server.
> Xcaml aims at being a Apache+Tomcat+JSP+Servlet replacement. The Xcaml 
> virtual machine and API are already complete, but the performance which 
> they achieve in conjunction with Apache is mediocre. Gerd's new HTTP 
> connector Ocamlnet will give us top notch performance while without 
> sacrificing the safety guarantees of the Ocaml language and VM.

Let me also add a few words about this project. What we are going to
implement here is nothing else but a web server written in O'Caml, or
better a web server component that can be integrated into the
application it is serving. Of course, this web server will have
"industry quality", especially regarding stability and performance. The
HTTP kernel is already written, and implements event-driven message
exchange for HTTP/1.0 and 1.1 in only 1200 lines of code.

Another part of the web server is called the "reactor". It provides a
Netcgi-compatible interface into which existing applications using
Netcgi can be simply plugged in. That means it will be quite easy to add
the web server component to existing CGI applications. The reactor
processes one HTTP request after the other, and can call an arbitrary
content generator for every request. To achieve parallelism, it is
planned to integrate the reactor into a multi-threaded setup.

I am also figuring out a purely event-based implementation (using only in the hope that the simplification of scheduling will give
us a performance boost. This setup will be a lot more complicated, and
when carefully combined with multi-threading or -processing it will also
be possible to plug in existing Netcgi-based application in addition to
purely event-based content generators, i.e. the best of all worlds.

As you can see, some aspects of the web server design follow
conservative ideas (like the reactor), and some are very experimental. I
hope this results in a top-performing server that can be configured in
very flexible ways.


> The new library will be released to the community by Baretta DE&IT and 
> Gerd Stolpmann jointly under the terms of the GPL. When the integration 
> with the Xcaml server will be done, the full Application System/Xcaml 
> will be released under the terms of the GPL.

> Alex
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany