On Mon, Mar 15, 2010 at 5:38 PM, Gregory Collins <span dir="ltr"><<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>></span> wrote:<br><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm seeing a lot of energy being dedicated to standardizing interfaces,<br>
which I suppose is an admirable goal, but to me it's putting the cart<br>
before the horse: what's the point of having a standardized adapter when<br>
there's nothing worth plugging into it, besides some middleware that<br>
your framework should be providing for you anyways? </blockquote><div><br></div><div>In the case of happstack, I have felt that the lazy I/O based server back end would ultimately be a liability. That we ultimately need to be able to use something enumerator based. Additionally, the lazy I/O backend part of happstack-server is the least interesting part of the project. It just takes extra resources to maintain, but provides nothing especially unique. </div>
<div><br></div><div>Moving to Wai should put us in a much better position to use a fast enumerator based backend -- and with out having to write one ourselves. Plus it should make it easy for people to use CGI, fastCGI, etc. We have some adapters for that already, but the Wai solution seems cleaner. If you want to use happstack-state, then you still need a process that runs fulltime, but if you just want to use the ServerMonad stuff provided in happstack-server, then CGI should be fine.</div>
<div><br></div><div>Some from the point of view of a framework developer, it's not 'the middleware that your framework should be providing', but rather 'not having to reimplement existing middleware when I could be doing something cooler'. And, it also means that we can more easily share pieces of our framework with others. Many people are not interested in happstack-state, but might be interested in happstack-server. So, making it easier for them to use just that little piece is good for us.</div>
<div><br></div><div>There is certainly a point where we won't see much increased returns from standard interfaces though. </div><div><br></div><div>- jeremy</div><div><br></div></div>