Re: [Caml-list] CamlGI question

[Michael Alexander Hamburg <hamburg@fas.harvard.edu>]

Given then that my application should be multithreaded, and will be
running on a webserver using Rails (which traditionally uses FastCGI),
which of these libraries do you suggest that I use?  Http, Netcgi_afp or
Netcgi_fcgi?  Or are they interoperable enough that it doesn't matter?

Thanks a lot,
Mike

On Mon, 18 Apr 2005, Gerd Stolpmann wrote:

> 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
> Unix.select) 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.
>
> Gerd
>
> > 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
> gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>
>
> _______________________________________________
> 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
>