Alex:
I support your idea of making the thing happened, although
I do not know yet when I could contribute to it since I have
massive committments to other projects now. But I'll try.
If further discussion of these matters goes underground
please keep me posted, anyway.
One big chunk of work that you have not mentioned would be
related to multithreading. The server that I shortly described
in my previous post employs forking. The obvious improvement
would be to use Posix threads instead. Ocaml users are here
in much better position since native threads are strongly
supported by Ocaml. After all Xavier Leroy is not only a principal
developer of Ocaml but also an author of LinuxThreads - a de facto
standard library of Posix threads for Linux.
But this is doable even for Haskell. I have done some work
in multithreading area too, as you might have known from my web
pages.
I have found my previous work regarding Haskell Server
so I can now tell you more about its structure.
First of all, I have developed two versions of Haskell Client -
one browser based and one terminal based. The latter was mainly
used to simulate several simultaneous users. I would open two or
more terminals running Haskell Client and try to swamp my
version of Haskell Server with simultaneous requests. Both
type of clients can run either locally or over the network.
The server is able to differentiate the type of clients
and formats its output accordingly - either as text or html.
Haskell Server is made of three parts:
- A front end dealing with network connectivity, forking
and piping of Hugs input and output to proper clients.
I call it hserver.c.
- A lightweight replacement for original "Haskell Server",
server.c (found in Hugs distribution, as I remember it now).
I call it lite_srv.c
- Haskell modules handling parsing and evaluation of
Haskell expressions. My server is devoted to numerical
expressions, but you can do your own kind of job here
instead. I did not need the "state" at all, but you
certainly would need monads for your type of applications.
The good news is that all that specialization takes
place at the Haskell level, not C.
To make a complete Haskell server for network applications
you would copy the Hugs source code distribution, replace
original server.c by lite_serv.c, incorporate front end
hserver.c, make apropriate changes to makefile and run
make.
Why did I replace the original server.c by my own version?
Below is a copy of my description from file lite_srv.c:
// Module:
//
// lite_srv.c - Light version of Hugs server API
//
// Description:
//
// Minimal implementation of the Hugs server API that was specified
// by Hugs design team. See "server.html", "server.c" and "server.h"
// that are part of Hugs source code distribution.
//
// This version is based on their original server.c but is
// significantly simplified. The important changes are as follows:
//
// -- Only 6 out of 19 original server API functions are retained,
// that is: only those functions that are needed to load and
// compile user script, and find and execute a startup function
// from a selected Haskell module. (In case of our hserver,
// the function name is "hserver" and the module is Hserver.hs)
//
// -- Compiler is used only to compile initially loaded Haskell
// modules and is NOT employed in evaluation of dynamic
// expressions.
// If Hugs authors deliver their promise to implement a mechanism
// of linking precompiled modules, such as Prelude, than the
// compiler will not have to be linked at all to programs
// using this module.
//
// -- Evaluation of dynamic expressions has been shifted from C side
// to Haskell side. Our module Evaluator.hs and a set of modules
// hparser from Aachen University handle the evaluation instead.
// This slows down the evaluation process of course, but it makes
// it easier to design various programming interfaces. For
// example,
// our Haskell Server is made of a front end C module "hserver.c",
// which handles all network communication, and this module that
// links Haskell code for evaluation of dynamic expressions.
// The two modules are parent and child processes that communicate
// via two Unix pipes.
//
// -- Original server.c compiles and loads Haskell module
// "Dynamic.hs" (together with "Prelude.hs") at initialization
// time. For various
// reasons this module uses our module "Dyna.hs" instead. Dyna
// is a modification of Dynamic. Aside from some bug fixes, Dyna
// handles user errors in a more graceful way than the original
// Dynamic.
// Accordingly, function linkDynamic () in original server.c
// has been replaced by linkDyna (), and a number of references
// to Dyna module significantly reduced to include only those
// really needed.
//
All the above (and possibly multithreading modification)
could be my contribution to a project. The only reason
that I have not posted it so far is that I do not have
enough time for testing. I dislike publishing things
with too many loose ends. On the other hand I have
developed this stuff in July 1998 - almost a year ago!
One of these never published projects - so it seems, he-he.
But if there is a real interest in this sort of things
and if you put enough pressure on me I might break
my "unhealthy" habit this time. :-)
Jan
