I would love to see your mod_ocaml code.
I don't know how much I will be able contribute as I am learning.
However it would be a good learning opportunity for both OCaml and the
Apache API.

A quality mod_ocaml would potentially help OCaml gain mindshare in the
web development arena. Since OCaml is a good general language, that use
could spill over.

A good architecture first, then performance.
It would be nice to have either in this module or loadable from this
module a module for a pool of database handles. That way we could have
persistent connections to the database.

Just some thoughts.

Thanks for you input (both of you).
I look forward to seeing your code.
Email it to me or send me a link.

Thanks.

Jimmie Houchin

Samuel Heriard Dubreuil wrote:
> 
> > > Is there any interest in a mod_ocaml or a fast-cgi module for OCaml?
> > > I haven't a clue on how to develop either but could possibly learn. :)
> > > After learning OCaml (at least some) first.
> >
> > If I understand correctly what you mean by mod_ocaml (packaging
> > OCaml runtime environment in a Apache module, in order to avoid to
> > load it for every request), Samuel Heriard (in Cc)
> > started such a project; I don't know how the progress status.
> 
> That's right, I started to write a mod_caml (a la mod_perl). I've not been
> working on it since six months, but it does work under apache 1.3 (at
> least "Hello world !").
> I didn't worry too much about performance issues because I wrote it in
> one afternoon mainly to learn the apache api. But I'd like to restart working
> on it.
> The principle was to associate the caml handler to .cmo files, dynamically
> load  $DocumentRoot/bar.cmo on a request to http://foo.com/bar.cmo, let the cmo
> do the job, and then unload it. The goal was to create something like jsp.
> I know it's pretty inefficient, but with a cache system, you would not
> have to load/unload a .cmo for each request.
> 
> > The GC should'nt be a big problem: between two requests, the runtime
> > environment can completely flush the heap (excepted for the
> > connection/persistency manager). But I may miss some important issues.
> 
> The connection manager is an orthogonal problem. A connection may use
> several instances of the runtime (several apache process) so I think it
> has nothing to deal with the garbage collector (one can use files, shared
> memory or db to store the connection informations).
> 
> So if you're interested in working an a mod_ocaml, let me know, I'll send
> you the code (actually not more than a hundred lines of caml/C if I
> remember).
> 
> --
> Samuel
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr