From: Francois Berenger <berenger@riken.jp>
To: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: [Caml-list] library/framework needed for distributed programming in OCaml
Date: Wed, 11 Jul 2012 15:40:09 +0900 [thread overview]
Message-ID: <4FFD1FC9.5040109@riken.jp> (raw)
Dear list,
Please forgive me to open this possibly re-occurring thread
but I need an up to date version of the answer.
I once wrote a parallel and distributed toy program
in Python which proved to be quite useful (
http://savannah.nongnu.org/projects/par/
).
It was quite simple and easy to write because I used
a "library that enables you to build applications in which objects can
talk to each other over the network" (http://pypi.python.org/pypi/Pyro4).
So, I am looking for the gold standard to write
modules in OCaml that can talk to each other over the network
(not objects, I don't like them so much).
Here are some requirements, in a random order:
- the target execution environment is composed of
about 10 Linux workstations. It may switch to 1 or
2 interconnected clusters in the future (about 512 cores max).
So, not as large a scale as a company doing big data.
- the system will be used to transfer files of various sizes
(big files like a few Gb included, tiny ones also)
- pure OCaml code, so JoCaml and CamlP3l are out.
I don't like so much if there is some C part in the library
but this is not a show stopper.
- I really dislike syntax extensions (or things that force
me to do a lot of sysadmin strange configuration) so user-land only
would be great
- preserving type-safety and abstraction as mentioned
in the Quicksilver/OCaml paper would be cool (
www.kb.ecei.tohoku.ac.jp/~sumii/pub/qs.pdf
) but not mandatory.
Ideally, encryption or compression of communications should
be a user-toggable feature.
- tolerance to partial failures would be nice but not
mandatory (because my target environment is not so error prone
and not so large)
- the project should be actively maintained and preferably used
in production somewhere ("je n'aime pas essuyer les platres")
- I don't like to use huge frameworks/libraries (j'essaye d'eviter "les
usines a gaz")
I would be satisfied with even just links to things that
satisfy most of my requirements.
For the moment, the few things that I could find that looks useful are:
- Client-server part of
http://caml.inria.fr/pub/docs/oreilly-book/html.bak/book-ora187.html
- maybe the SunRPC part of
http://projects.camlcity.org/projects/ocamlnet.html
Thanks a lot for your suggestions,
Francois.
next reply other threads:[~2012-07-11 6:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-11 6:40 Francois Berenger [this message]
2012-07-11 10:21 ` Lauri Alanko
2012-07-12 8:46 ` Francois Berenger
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=4FFD1FC9.5040109@riken.jp \
--to=berenger@riken.jp \
--cc=caml-list@inria.fr \
/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