[Haskell-cafe] Web server libraries

Sterling Clover s.clover at gmail.com
Fri Mar 28 00:07:08 EDT 2008


While hvac, which I announced here recently, is not yet ready for  
primetime, so to speak, you may want to take a look at it -- with a  
few tweaks it should match your specs. (darcs get http:// 
community.haskell.org/~sclv/hvac/)

It does include some templating, though you don't have to use it  
significantly, but then again, I find it hard to automate data  
validation without it (how else do you control showing results?), and  
it does allow for session support, although it isn't necessary.

It is, however FastCGI based and has built-in connection pooling. It  
should theoretically be able to speak to any database that HDBC  
speaks to, although it does need a little work (here's the  
modification issue) to ensure the strong atomicity constraints work  
properly with anything but sqlite.

Additionally, the validation functionality should be very powerful  
and intuitive, and the control flow combinators equally so, which are  
also written to parse RESTful parameters as part of url strings as well.

Not sure what you mean by marshalling to-from Haskell types -- the  
validation provides one side of it, and on the other,  as you well  
know, HDBC gives a very convenient way to deal with the SQL end :-)

The less tested/more dicey parts of hvac are all those that deal with  
atomicity and caching, and if you're not relying on those, then that  
shouldn't be an issue either. And the only questions there, in my  
mind at least, are to what degree running everything out of STM (i.e.  
optimistically) could lead to problems in high-contention  
environments -- so again, possibly not an issue for your needs in any  
case.

As for event model -- hvac tries to be nonjudgemental, though it is  
request rather than continuations-based and is mainly designed to be  
REST. One could implement a "conversations" layer over sessions  
without too much work -- alternately, control flow can be parameter  
based, much as one would do in plenty of other web frameworks.

Finally, although the atomic stuff is what makes hvac fun, one could  
rip out either the controller or validation sections without too much  
work and act directly over FastCGI. On its own even, the FastCGI lib  
isn't perfect, but as Paul Brown noted, its not too hard to build a  
few nice structures on top of it to handle whatever you throw at it.

Regards,
Sterl.

On Mar 27, 2008, at 3:26 PM, John Goerzen wrote:

> Hi again,
>
> I'm currently working on a project that has a Web interface to data
> stored in a SQL database.  I wrote this thing in WASH a few years
> back.  Overall, this has been acceptable, but the non-Haskell-adepts
> around here run away screaming from the code.  Not only that, but we
> don't get control over the names of the form elements, which can make
> interacting with other software that sometimes plonks users down
> halfway through the process -- well, interesting.  Also, WASH supports
> nothing better than CGI, which is a big minus when talking to SQL  
> databases.
>
> What I really want is some sort of simple tool that supports FastCGI
> or some such, has basic support for form data input validation and
> marshalling to/from Haskell types, and basic control flow.  I don't
> need, or really particularly want, something that uses hs-plugins to
> compile pages on demand (I'm using Haskell for it's static safety,
> after all).  Nor do I need fancy templating systems or session support
> (we use HTTP auth and are fine with it for now.)
>
> So I've looked around a bit at the landscape.  Any recommendations?
>
> I've found these:
>
> HSP: big on "dynamic pages".  I don't want to make my webserver able
> to compile Haskell code.  Develop code, compile, test, make sure it's
> right, then push to production every 6 months around here.
>
> WASH: Pretty much the right niche, but the event model is hard to use.
>
> HAppS: Frankly it is a big collection of confusing packages to me.   
> What
> documentation exists doesn't seem to be relevant anymore, and it seems
> to be designed to not use a SQL database.
>
> FastCGI: Relies upon CGI for a good part of processing.  Does not seem
> to have any form data validation support built in.
>
> Thanks again,
>
> -- John
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



More information about the Haskell-Cafe mailing list