Web framework: WAI instead of Snap

[gregwebs]

I think this library should be able to drop the snap dependency and be framework independent.

[chrisdone]

Agreed completely, Greg. I picked this as it's the one I already knew. I think I'll take that dependency out and then in the examples I can do a few different frameworks.

[scitesy]

+1 and Yesod for sure:)

[gregwebs]

Actually, I think WAI is a much better target to start with than Yesod specifically.

[scitesy]

Good point.

[chrisdone]

WAI would be logical to continue this simple signal/poll request approach that I'm taking presently. As I only use:

import Snap.Core (Snap,route,modifyResponse,Cookie(..),
    setHeader,getsRequest,Request(..),MonadSnap,writeText,getParam,setContentType)

Another option would be for me to migrate the code to websockets (which was part of the plan anyway), in which case it'll run on anything that implements websockets (and there is already a WAI wrapper for websockets in the WAI package). I think I will try this as it supports browsers that don't have websockets via Flash.

[joeyh]

+1 to this. WAI is the way to go, and would make it easy to integrate with Servant too, via Servant.API.Raw.

threepenny-gui has transitioned to websockets since the last post here.

This seems like it would be fairly easy to do now. My plan would be:

• Convert httpComm to a WAI Application.
• WAI has no routing of its own, so use a minimalistic WAI routing library, like wai-route to replace the current routeResources.
• Make Foreign.JavaScript.serve to use warp to serve the WAI Application.
• Add UI.ThreePenny.mkWAIApplication :: Config -> (Window -> UI ()) -> Application so that users who need more than the built-in warp server can make a WAI Application to serve as they please.

So it would depend on wai, wai-route, and warp. Does this seems a reasonable plan?

[HeinrichApfelmus]

Reimplementing the web server on top of WAI seems fairly straightforward indeed, since the HTTP-related code is mostly confined to the Foreign.JavaScript.Server module.

It's not something I intend to implement myself, but I'm happy to accept and maintain contributions on this, so go ahead if you feel like implementing this.

[sjakobi]

I would also like to see threepenny-gui move from Snap to WAI, mostly because I think that this would make it easier to keep threepenny-gui on Stackage – the Snap maintainers don't seem to have much interest in keeping Snap on Stackage, so I'm currently sharing some of that burden.

What isn't clear to me is how the cookies handling added in https://github.com/HeinrichApfelmus/threepenny-gui/commit/6bc3cfad5f8a7d2fa4219b3f49d58a7c5ab18599 should be adapted – we're using snap-core's Cookie type there. Should we add a dependency on cookie or just work directly with the ByteStrings that WAI offers?

(/cc @blitzcode)

[HeinrichApfelmus]

I was somewhat fond of the Cookie type introduced by snap-core, but it appears that it contains more information than a web browser actually sends. With that in mind, I think that depending on the cookie library is fine — it's not our job to reinvent bakery items. :wink: ThegetCookies functions should then return the Cookies type from that package.

This change makes it necessary to increase the major version number.