[web-devel] Hoogle Advice

[Michael Snoyman]

On Tue, Jan 25, 2011 at 7:35 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:
>
> On Jan 25, 2011, at 1:33 AM, Bardur Arantsson wrote:
>
> I'm actually considering using WAI for two of my projects as well. I haven't
> had the time to actually try it, but I'm pretty sure I'll be doing it for at
> least one of these projects.
>
>
> The second one *is* a framework (just started, hopefully I'll actually
> finish it) for Rich Internet Applications a la Wicket, Vaadin and Echo3.
> Essentially you (as the framework user) program your application in a
> "magical" monad which turns widgets, components and other logic into a
> combination of browser JavaScript/Ajax calls and server-side logic for
> processing state updates. I think using a low-level API like WAI is also
> quite justified in this case simply to avoid huge dependencies. The only
> thing that I'm likely to have to "reimplement" is a little bit of routing
> (but that's a trivial amount) and some handing of cookies/sessions (though I
> may be able to avoid that in the short term). There will also be some
> autogenerated JavaScript and such, but that's such a niche thing that I
> wouldn't really expect much support from a general framework for such a
> thing anyway.
>
> 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.
> 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
>  2. a cookie API
>  3. a rich API for serving static files (which  handles things like
> 'if-modified-since' automatically)
>  4. a rich API for extracting values from cookies, query parameters, and the
> request body
>  5. support for file uploads
>  6. support for automatic compression of Response bodies
> 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 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.
> 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. :)
> - jeremy
> p.s. I am interested in possibly moving happstack to be built on top of WAI.
> I even did an experimental port once just to confirm that it  would be
> feasible. The biggest hold up at the moment is probably the lack of timeout
> handling in warp. Though maybe that has been added now ?

Yes, the timeout handling is in. I intend to move to your new timeout
code when I have some free time to work on it. Of course, the whole
point of having WAI/Warp would be that we could collaborate on these
kinds of projects, so if you want to help out, it will definitely be
appreciated.

Michael