<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 25, 2011, at 1:33 AM, Bardur Arantsson wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>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.<br><br><br>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.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>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. </div><div><br></div><div>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:</div><div><br></div><div> 1. RESTful-style routing combinators like (dir, path, etc), or type-safe urls via web-routes</div><div> 2. a cookie API</div><div> 3. a rich API for serving static files (which handles things like 'if-modified-since' automatically)</div><div> 4. a rich API for extracting values from cookies, query parameters, and the request body</div><div> 5. support for file uploads</div><div> 6. support for automatic compression of Response bodies</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. :)</div><div><br></div><div>- jeremy</div><div><br></div><div>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 ?</div></body></html>