[web-devel] Next version of WAI: cleaning house

[Michael Snoyman]

Thanks to everyone for the fruitful discussion in this thread. I think
we've come to most decisions here already, so I'm making this a last call
for input before I start implementing the changes. Once the changes are
implemented on a separate branch, I'll send another email asking for review
before actually releasing the changes to Hackage.

If you have any more ideas to share for WAI 2.0, please bring it up before
the end of this week.


On Tue, Jul 23, 2013 at 1:04 PM, Michael Snoyman <michael at snoyman.com>wrote:

> 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:
>
>    - 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`.
>    - Kazu has mentioned to me in the past that, based on his profiling,
>    monadic bind for ResourceT may currently be a bottleneck in WAI.
>    - 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]).
>    - Kazu checked out the performance difference of this new branch, and
>    it allows for some better optimizations.
>
> 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?
>
> So as long as we'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:
>
>    - Remove the deprecated isSecure field from the Request data type.
>    - Remove the misleading fields serverName and serverPort fields as
>    well.
>    - Possibly: hide the Request constructor so that new fields can be
>    added without breaking backwards compatibility.
>
> If anyone else has some ideas, please bring them up.
>
> [1]
> http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/resourcet/Control-Monad-Trans-Resource.html#g:10
> [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't affect most Yesod users at all.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20130812/36bc1113/attachment.htm>