On Mon, Jan 24, 2011 at 4:38 PM, Neil Mitchell
I think WAI could be increasingly used - its at a level of abstraction that I quite like. I certainly have other projects which I will probably switch over to WAI/Warp.
I am curious to see how your feelings on this change or stay the same over time. The basic WAI abstraction is very nice. You essentially supply a function, Request -> IO Response, that will be used to handle incoming Requests. It is very straight-forward and obvious what is going on. At first this is very attractive. It makes it very easy to get started. But at the same time, it doesn't do much for you.. I wonder if you will ultimately end up recreating a higher level framework in your WAI based applications. For example, you might decide that passing the Request around explicitly is tiresome and stick it in a Reader monad. When looking up key/value pairs from the query string or post data, you might want more expressive combinators for validating the values and converting the string data to haskell types. You might find that sometimes you need to escape early and return an alternate page. You might realize that the Response is going to need some extra headers (like the Cookie field) but be in a spot in your code where the Response has not been created yet. So you will need a filter, or something, that can add the header later when the Response is created. And, of course, you need some way to look at the pieces of the url and map it to a handler. These are the types of features (and more) that exist in the higher-level frameworks like Happstack, Snap, and Yesod. In theory, that is the value they add over just using WAI. It is likely that, in the future, happstack will not include it's own http backend, but be a layer on top of WAI+warp, hyena, or some other low-level WAI-like HTTP backend. So, I am curious if the value-added features we provide actual provide value :) One measure of this will be if you end up creating similar adhoc functions and structure in your apps. - jeremy