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
[Caml-list] building web services using oCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-09-17 (04:57)
From: Arnaud SAHUGUET <sahuguet@l...>
Subject: [Caml-list] building web services using oCaml

I am looking for ways to build web services using oCaml.
(* this effort is part of the GALAX project at Bell-Labs. See for more info. *)

First I would like to point that out this includes two different aspects:

1- building the web services themselves (e.g. putting a SOAP interface on top of a database and spitting XML)
This is the server side, if you will.

2- glueing together web services
This is more the client side.

For 1-, it is not clear to me that oCaml has a competitive edge compared to other approaches, mainly because 1- requires a lot of "legacy" libraries not necessarily available for oCaml.
For 2-, however, the main components needed are an HTTP stack (HTTP, TCP, SSL, etc.) and an XML stack (XML parser, etc.). And this is where a functional language can really show its value.

I was looking at:
- ocamlNet
- cgi
and they support some aspects but not all that is needed like SSL, cookies, etc.
Are there other libraries that would do that for me?

As a more general question, shouldn't we (meaning of "we" to be defined :-) implement these stacks in oCaml?
Is there any value in doing it (except for the experience and fun of doing it)? 
Is there any advantage in having the stack (and whatever is underneath) available as oCaml constructs?

These protocols are complex and keep evolving. Taking a reference implementation (like libwww which is complete, maintained, supported and updated) and adding oCaml wrapper on top would make more sense to me. Our value added would be in the design of a nice API on top.

I am not saying that this should be done for everything, but when there is no (or little) value in having the low-level implementation details available as oCaml constructs, this is -- from my point of view -- the way to go.

I would like to raise the same question for XML libraries where namespaces, entity resolution, XML schemas (and God knows what they are going to invent) need to be supported. Should everything be done in oCaml? What is the value of having the low-level implementation details of XML trees available as oCaml objects?

As mentioned on various previous postings, the oCaml community is smaller than the Perl or Python ones. We need to be smarter and nimbler in our efforts.