<div dir="ltr">Some of you may have seen the brief interchange between Kazu and myself regarding ResourceT in WAI. Let me give a very brief synopsis of the situation:<div><ul><li>In order to allow WAI applications to acquire scarce resources like file handles in an exception-safe way, WAI actions all live in a `ResourceT IO` monad, instead of just `IO`.</li>



<li>Kazu has mentioned to me in the past that, based on his profiling, monadic bind for ResourceT may currently be a bottleneck in WAI.</li><li>I made an experimental change to WAI so that, instead of actions living in `ResourceT IO`, the WAI Request value contains a ResourceT InternalState value, which can be used to accomplish the exact same thing as living in ResourceT (see [1]).</li>



<li>Kazu checked out the performance difference of this new branch, and it allows for some better optimizations.</li></ul><div>If this was purely a performance optimization, I would probably just optimize Warp and not bother changing WAI. However, I think that this change makes WAI itself better as well, and therefore am in favor of making this as a breaking change, releasing it as WAI 2.0[2]. Firstly, are there any objections to this move?</div>


<div><br></div><div>So as long as we&#39;re making a breaking change, the question arises: what other changes should we be making to WAI? I know Kazu had mentioned adding fields to avoid the need for lookups, can you clarify that request a bit? Here are some other changes I can think of:</div>


<div><ul><li>Remove the deprecated isSecure field from the Request data type.</li><li>Remove the misleading fields serverName and serverPort fields as well.</li><li>Possibly: hide the Request constructor so that new fields can be added without breaking backwards compatibility.</li>


</ul><div>If anyone else has some ideas, please bring them up.</div></div>
<div><br></div><div>[1] <a href="http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/resourcet/Control-Monad-Trans-Resource.html#g:10" target="_blank">http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/resourcet/Control-Monad-Trans-Resource.html#g:10</a></div>


<div>[2] For the Yesod community: the change is minor enough that Yesod 1.2 can have some conditional compilation to support both the current WAI 1.4 and WAI 2.0, so this shouldn&#39;t affect most Yesod users at all.</div>



</div></div>