
On 2011-01-25 18:35, Jeremy Shaw wrote:
On Jan 25, 2011, at 1:33 AM, Bardur Arantsson wrote:
I think there are a lot of things you might want from a slightly higher level framework like happstack-server. Note that you can install happstack-server with out happstack-state or any of the templating libraries.
Possibly. However, I'm not really sure it's worth the extra dependency. Btw, I actually tried to convert my Hums project to Happstack. There was some crucial problem which I was not able to overcome. I think it *might* have had something to do with not wanting to use Sendfile (the old thread/FD leak problem) and not finding another way to do the same thing without using Lazy I/O (which I *definitely* don't want for transferring huge files to a crappy HTTP client). I'm not entirely sure that was what the problem was, but if it sounds plausible, then there might be a feature request lurking there :). This is just to say that I have actually tried Happstack.
You could then create your magical monad by adding some additional layers to the ServerPartT monad transformer. By using happstack-server you would get access to:
1. RESTful-style routing combinators like (dir, path, etc), or type-safe urls via web-routes
I don't really think I'll need this; my routing is simple enough that a couple of "stripPrefix" calls will do the trick.
2. a cookie API
I'm _probably_ going to be able to avoid cookies entirely, though I'm not 100% sure at this point.
3. a rich API for serving static files (which handles things like 'if-modified-since' automatically)
I probably won't be serving static files :).
4. a rich API for extracting values from cookies, query parameters, and the request body
Again I'm not really sure this buys me anything. All my browser side code will be auto-generated, and AFAICT WAI already gives me relatively convenient access to all the bits I need (modulo cookies).
5. support for file uploads
Probably not going to be needed, though I suppose it might be in the long term.
6. support for automatic compression of Response bodies
I think there's also a WAI middleware for this in wai-extra unless I'm mistaken?
And the default ServerPartT monad gives you easy support for accessing the Request, applying filters to the Response, aborting/escaping the current computation and returning a different Response, support for throw/catch, and more.
I don't doubt much of this is convenient if you're writing an *application* on top of Happstack, but again I'm not sure it's really worth it in my case. This may change as I get closer to actually producing working code :).
I have done some work on trying to create a high-level haskell DSL which automatically generates client-side javascript+html, communication via JSON, etc. I personally found building on top of happstack to be useful.
Is this available anywhere? I'd love to see what you came up with.
The dependency list for happstack-server is not all that different from wai+wai-extra+warp. So concerns of a 'huge dependency list' are perhaps overblown.
The point being -- if happstack-server were built on top of WAI today, so that the choice was between wai or happstack+wai, I would still recommend that you consider happstack+wai as your foundation not just wai. :)
When I inevitably discover that I should have gone with WAI + Happstack it certainly might make "porting" easier :). Cheers,