>Right now we are use Haskell to pregenerate HTML/Javascript on Shop.com
>We would love to use it for dynamic page generation, it does not
>appear to meet our needs:
>
>* NT is not a reliable server platform so we can't use HaskellCOM
Many people would tend to disagree with your assertion that NT isn't a
reliable server platform - we have experience of hitting it very hard
indeed, both from the comms and the disc point of view. We have seen a few
failures, but almost all were traced to hardware outages (more specifically,
"Customer not buying decent hardware error at line 1536" problems). However,
Telergy has always supported failover and load balancing, so individual
machines going up and down has never been an issue anyway.
>* Haskell itself has no libs for database,network,files,ldap
Again, we aren't worried about that because Telergy does all of this anyway.
>* Haskell has no clean way to maintain a keep-alive connection w/ an httpd
I wouldn't expect it to - my plan was to build a 'channel' that would pipe
requests into the Haskell subsystem and return responses to the user. This
is not difficult under NT, especially with our libraries, due to having
events, mutexes and threads with shared memory available.
>A straightforward solution to the lib problem would be to give Haskell
>the ability to use Java libs. These libs have clean well define APIs that
>are easy to represent in Haskell. The difficulty is that:
>
>a. a haskell native interface is not well defined and implemented on
> hugs&ghc (though this is supposed to change RSN)
>
>b. the Java native call interface is a pain
> (it only recently became stable/usable)
>
>c. the build tools don't yet automatically generate Haskell modules for
> Java classes/packages
Linking to Java wouldn't be a solution for us, because we have a huge
investment in VC++ code already.
>All of these are solvable, but they are not yet solved.
>Claus Reinke <[EMAIL PROTECTED]> had been working on this but only in
>his spare time and is not making a lot of progress. We were thinking
>about taking a shot, but there is only so much time in the day.
>
>The third problem is also an implementation issue....
>You don't want to have to start a hugs process that makes a
>connection to a database everytime a user makes a request. You want
>something like mod_perl or jserv which keeps the interpreter
>alive to handle requests from the httpd. The other alternative is to
>compile GHC code into apache modules, but then you are back to the issue
>of having a standard native call interface to Haskell.
>(What would be really nice here is a Haskell servlet API which defines a
>datatype or class that a haskel servlet runner would take care of).
Probably the easiest way I can think of to solve this is to implement the
Haskell equivalent of a message pump, whereby the Haskell code makes a call
to a request broker when it is idle. When there is a request that needs to
be processed, the request broker returns the request. The Haskell code then
does whatever it finds necessary to service the request, calls the broker
again to return the result and goes back to waiting again. Assuming that the
request broker is well written (e.g. fully event-driven, multithreaded with
no polling or background processing), it would be possible to run multiple
copies of the Haskell process so that multiple queries can be processed
concurrently. This is important to us because we use SMP machines a lot, so
there is a significant payback from being able to do this. We have library
code that can do more or less everything necessary, so it shouldn't be too
hard. That said, doing this on Unix/Linux might be a fair bit harder,
because we do tend to heavily use NT's multithreading, IPC and
synchronisation features.
Sarah
