In my prior post I identified three problems with using Haskell at the server: 1. Need for non Unix server support 2. Lack of libaries 3. The lack of a mod_haskell or jserv like interface for Haskell In response to (1), Sarah Thompson emphasized her satisfaction with NT's stability. Regarding stability see http://www.unix-vs-nt.org/kirch. However, even if NT were completely stable, Haskell would still suffer from being limited to the win32 platform. Haskell will be a success if it is supported by the larges community possible. Since Haskell is relying on an opensource model, it should support the platforms most used by open source developers e.g. linux/unix. I know that MSFT is effectively subsidizing haskell development, but that doesn't mean that Haskell should not be cross platform. In our case, some of our developers work on win32, and others work on linux or solaris. We cannot use tools that are platform specific. Regardling libraries, Olivier Lefevre noted that the Java native call interface is now stable, but that does not mean there is not substantial work in making it easy to use those libraries from Haskell. Assuming everything is stable and working properly you need to do a lot of work: a. Learn HDirect well enough to write your own iface language (1 week) b. Learn Java Native Call Interface (1 week) c. Call Java from Haskell (3 days) d. Generate Haskell modules from Java class signatures (2 weeks) e. Create build tools that make it easy to access these java classes (2 weeks) f. Debug/test/cleanup (3 weeks) Sarah says: > >* Haskell itself has no libs for database,network,files,ldap > Linking to Java wouldn't be a solution for us, because we have a huge > investment in VC++ code already. You still have to deal with the issue of getting a consistent and easy to use native call interface accross Hugs and GHC on windows. A few months ago I took a shot at getting HDirect working with hugs on windows. It is possible but really non-trivial. More to the point, I was not convinced that my solution was stable/reproducible for each developer without a lot of installation overhead. Things may have changed in the interim, but I have not had the chance to find out. Sigbjorn, Mark, Simon, how close are we to a release of Hugs/GHC that linux, solaris, and windows users can download and get out of the box consistent native call functionality? > >* 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. [...] > 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 This is not "hard", but doing it right is a bit involved. Jan pointed out that he has done something similar with Hugs (I assume on Unix). But getting it right is still a bit involved. Linux has threads etc, but it is still substantial work to get running. * Build an Apache mod_hugs module(1 week) Apache is already built to take care of all the theading issues associated with HTTP serving. Apache modules are also reasonably portable accross operating systems so if you went this route, it would be nicer for the rest of us. The other approach would be to do a native call interface from Java Servlets then you are not bound to an HTTPd but you are bound to Java. Either way, you want to define an interface so that you can use both compiled or interpreted haskell. You want to shift to develop with intepreted Haskell, but the production server should run compiled haskell. * Define a Haskell servlet interface (1 week) You need to define an interface for your Haskell code e.g. > class HServlet a where > handleHTTPRequest::HTTPRequest -> IO HTTPResponse When I was first learning haskell I wrote a version of this based on Erik's CGI library. At this point I could probably generate a much better one quickly, but making sure it was all nice and functional and usable is still work. (You might want to define HTTPRequest so it carries user state, etc.) * State cache system (2 weeks) If you are building a highly scalable system, you don't want to hit the database on every request. Your server process needs a standard way of maintaining state for each user. With java servlets, you typically use a hashtable in your servlet class indexed by user cookies. Because Haskell does not have stateful objects, you need to define another way of maintaining user state. (My bet would be using the berkleydb lib that comes w/ GHC, storing the db in /tmp, but I have not tried it yet) * Define a url mapping system (3 days) When a request comes in of the form GET /hservlet/app1/fun?x&y&z you need to translate that into a call to (Foo.fun x y z) How do you want to do this? * Embedded Page evaluator (1 week optional but useful) You don't only want to execute functions in response to CGI queries. It is much nicer to write HTML pages that include evaluated code of the form <html>This is my html <script language=haskell context=/hservlet/Foo>map foo [1..10]</script> </html> But you need to decide whether you want the evaluator to be in the IO monad or just to execute putStr.show on whatever is returned. * Debug & Test (4 weeks) Self explanatory. So, it looks like we are talking a few months of full time work to get Haskell up to speed as an appserver. It would be GREAT if this was done, but no one individually has the time. The nice thing is that various pieces are parallelizable. If enough people are interested in making this happen, I'd be happy to help out. I have already written primitive versions of a haskell servlet API and the page evaluator. Jan appears to have already written some inproc connectivity code.... Sarah, it appears you are going to walk the same road... By integrating this codebase w/ the erlang load balancing system, we would end up with a functional and elegant Haskell application server. -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-212-697-0184 voice The Easiest Way To Shop
