From: "Arnaud SAHUGUET" <sahuguet@lucent.com>
To: <caml-list@pauillac.inria.fr>
Cc: <sahuguet@research.bell-labs.com>
Subject: [Caml-list] building web services using oCaml
Date: Tue, 17 Sep 2002 00:56:43 -0400 [thread overview]
Message-ID: <016301c25e06$b67e7230$0b1919ac@bl.belllabs.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]
Hi,
I am looking for ways to build web services using oCaml.
(* this effort is part of the GALAX project at Bell-Labs. See http://db.bell-labs.com/galax/ 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.
regards,
Arnaud
[-- Attachment #2: Type: text/html, Size: 4388 bytes --]
next reply other threads:[~2002-09-17 4:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-17 4:56 Arnaud SAHUGUET [this message]
2002-09-17 12:16 ` Xavier Leroy
2002-09-17 14:33 ` Arnaud SAHUGUET
2002-09-17 14:56 ` FYI about Galax [ Was: [Caml-list] building web services using oCaml ] Jerome Simeon
2002-09-17 15:07 ` [Caml-list] building web services using oCaml Stephen Tse
2002-09-18 18:57 ` Alain Frisch
2002-09-18 19:11 ` Arnaud Sahuguet
2002-09-19 7:03 ` openssl (was: [Caml-list] building web services using oCaml) Florian Hars
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='016301c25e06$b67e7230$0b1919ac@bl.belllabs.com' \
--to=sahuguet@lucent.com \
--cc=caml-list@pauillac.inria.fr \
--cc=sahuguet@research.bell-labs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).