[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