Re: [Caml-list] Web Development with OCaml

[Jimmie Houchin <jhouchin@texoma.net>]

First, I would like to thank all who replied.

Your replies encouraged me to start printing the documentation and start
learning OCaml. :)
I am also working my way thru the archives of the mailing list I've
downloaded.
Thanks for making them available. That is a great resource.

I have been keeping an eye on OCaml because of messages in
comp.lang.functional, the ICFP (?) competition results and then more recently
the Bagley Shootout results. 

The speed and memory results in the shootout are amazing. But what compounds
it is the LOC result. To me that indicates that a language does not have to be
verbose to be fast. 


My thoughts on web development (currently) :) and what brought me to OCaml.

I've been working with Python/Zope for web development. But I've been giving a
lot of thought to the architecture I want for my website.

I, like many entrepreneurs, have great hopes for my website. Because of this I
want my website to be fast, user-friendly and scalable.

Currently fast web servers like Tux 10-15,000+ rps (requests per second),
Apache 2-4,000 rps aren't dynamic (at those speeds). Dynamic website tools
like Zope, etc are either like 20-80 rps or some I've seen up to 100-200 rps.
This is a great disparity.

I want a dynamic website which gets as close to static speeds as possible.

Several ways to approach.

1. Tux. Use Tux as the front end webserver.
       Allow Tux to do as much serving as possible.
       Images, static content, etc.

2. Apache. Put Apache behind Tux.
       Use Apache, FastCGI, mod_ocaml(?) or some such
       for generating dynamic content.

3. Tux module. Create an OCaml user space module for Tux.
       This would be interesting and would probably be very fast.
       This is also beyond my skill.

4. OCaml CGI. Use traditional CGI with OCaml behind Tux.
       If OCaml's cgi spawns very fast or I guess is 
       preforked with a pool of processes. This could be pretty fast.

5. An OCaml Web Server. I don't know what's available here yet.
       I haven't had the time to research yet.
       This could be a very interesting option, especially if it's fast.
       This could easily be an excellent option to put behind Tux.
       Tux serves number 1. above and passes all dynamic services to this
server.

6. OCaml web app server.
       If all data was in a database for persistence and most pages were
templates,
       then many of the pages could be dynamically generated static pages.
       If most of the page is static then what options are available to allow
       the fastest server serve the static data and either the server Tux(?)
or Apache 
       request the dynamic data via SSI or the client request it via
Javascript.
       I do generally prefer the server-side option. I generally don't like
requiring 
       anything client-side, but if necessary or advantageous will take
advantage 
       of those who allow/permit it.

I believe there is an oportunity here to bring speed to dynamic websites with
OCaml.

Most people don't want to program websites in C. 
Perl, Python, et al don't compare speedwise.
Performance does matter.
Scalability does matter.
OCaml seems like a great tool to build a fast, developer friendly web app
server(?)/toolkit.

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.

Those who are using OCaml for web development. 
Are you doing traditional CGI behind Apache?

I have just read a babelfish version of Alain's page. Not perfect but
understandable.
We seem to have some common concepts/beliefs.

I hope some of what I wrote above is understandable, hopefully logical.
Maybe I'm just crazy. :)
Hopefully as I come up to speed with OCaml and what's available, I'll be more
coherent and rational in my questions or statements.

Any comments, pointers, wisdom is greatly appreciated.

Thanks again.

Jimmie Houchin
-------------------
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