On Fri, Sep 16, 2011 at 11:44 AM, Ertugrul Soeylemez <e...@ertes.de> wrote: > Michael Snoyman <mich...@snoyman.com> wrote: > >> Nice to see another project taking advantage of WAI and Shakespeare. I >> look forward to seeing some example code as well, though I personally >> am very wary of continuation-based frameworks. > > AFRP uses continuations under the hood, so you can view webwire as > continuation-based to some extent. But out of interest, why are you > wary? This is highly experimental work, and I see some problems coming: > > * Lower performance, though that can be fixed. Right now I'm getting > up to about 8000 requests per second using apachebench with -n 10000 > and -c 1000, which is probably not enough for high volume sites. > > * Sessions are a runtime-only phenomenon. This is a more serious > problem, for which I don't currently have a general solution, though > for most applications specialized solutions can be written. > > * FRP and netwire in particular have a steep learning curve. > > If you see any further potential problems, I'd be very grateful, if > you'd let me know.
I'm not sure what you mean by runtime-only, could you clarify? The reason I'm wary of continuation-based frameworks is that (at least from what I've seen) they are purposely non-RESTful. I know REST is a buzzword, but the other way to put it is: you're going to end up working against most of what HTTP is doing. There are good reasons why HTTP is stateless, and that shouldn't be circumvented lightly. I don't want to go too far on this right now, as I'm not an expert on cont-based frameworks, and I'm certainly not sure how webwire works. But from what I've seen in the past, you end up with ugly URLs and bad caching behavior. I think web developers *should* have to think about the fact that a page request is an inherently stateless operations, and storing state data should be a huge exception[1], not the norm. Michael [1] Obviously, there are some *common* exceptions, like authentication. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
