[web-devel] Hoogle Advice

Bardur Arantsson spam at scientician.net
Tue Jan 25 20:18:09 CET 2011


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,




More information about the web-devel mailing list