[Haskell-cafe] What is the maturity of Haskell Web Frameworks

Sterling Clover s.clover at gmail.com
Wed Jun 4 15:00:08 EDT 2008


>
> hvac sounds interesting but at that time at least it was not clear
> whether it was stable or would continue to be maintained.
>
> xhtml and HStringTemplate were overkill for what I wanted, so I  
> wound up
> just using the FastCGI and CGI toolkits themselves.  They are
> surprisingly nice, and with a little bit of wrappers around them for
> things like validating forms, have worked exceptionally well.
>

I'm in a position now where I can make a reasonable promise that hvac  
will not only be maintained but undergoing continued development. I  
just, for example, hooked in some basic postgresql support yesterday  
(although the changes are not tested/pushed to the repo yet).  
(Speaking of which, I noticed that the HDBC postgresql bindings don't  
set seState on an error -- is this intentional, or something that  
should be fixed up?)

As such though, I also can't promise that hvac as it stands is  
officially stable, although most work I imagine that will be done on  
it will consist of extensions rather than API-breaking changes.

I've also been working on a lightweight testing API for programs  
using the CGI monad, integrated with quickcheck. Although this  
project isn't "final" yet either, there's a working repo at http:// 
code.haskell.org/~sclv/cgicheck/ if anyone wants to play with it/use  
it. I plan to use this quite a bit to test hvac, and any applications  
produced using it.

Additionally, the hvac code now has a nice, though also incomplete  
orm/dsl-type library for database access (also built on top of HDBC).  
When I feel more confident/polished in the code there, I plan to  
split it out and hackage it as well.

Of course, folks with a little time/inclination who play with these  
things a bit and put them through the paces are a big help in working  
out the kinks such that I feel they're closer to "release- 
quality" (even if that "release" *is* only 0.1). :-)

Relatedly, I'd be very interested in developing a single common  
library for encoding/escaping/decoding/unescaping of common web  
formats (urls, javascript, basic xss escaping, rss-valid character  
escapes to html-valid ones, etc.) that uses a lightweight invertible  
combinator approach as described in Pierce's work on lenses (various  
papers at http://www.seas.upenn.edu/~harmony/) such that the encode/ 
decode methods are correct-by-construction bijections. There are  
various encoding bits scattered among the Haskell web libraries at  
the moment, each with varying degrees of correctness and conformance.  
It would be nice to direct energy here to a single centralized  
project, which would have some upfront architecture, and then,  
unfortunately, probably no small degree of spec-translation. If  
anyone else is interested in working on such a thing, I'd be  
delighted for ideas/collaboration (or better yet, if someone just  
picked up the idea and ran with it themselves!) (hmm... maybe galois  
has some internal libraries it wouldn't mind sharing as a partial  
basis?)

Regards,
Sterl.


More information about the Haskell-Cafe mailing list