Thanks again for starting the discussion!
As I mentioned, for Servant I think it's unlikely we'd completely move away
from our current handlers, since we don't want to lose all the type
information we have, and don't want to impose such information on others.
So I'm hoping the next best thing might be achievable - allowing the
new-style handlers to be run directly, and having conversion functions from
our current handlers to the new style. I think the first is easy, and the
second possible. Since there isn't enough information at the value-level to
establish where it is our handlers are getting their arguments from (query
string, headers, request body, etc.), we'd need a Proxy argument for the
relevant part of the api. Something like:
convert :: (CanConvert api x) => Proxy api -> x -> NewHanderM ()
Where 'convert' would need to walk down the arguments of x and pull
arguments from the appropriate places. E.g., if
x ~ Int -> Person ->
ExceptT ServantErr IO (), and
api ~ Header "H" Int :> ReqBody '[JSON] Person -> Post '[] ()
we'd have 'convert' conceptually doing: convertExceptT $ liftM2 x
(parseHeader <$> getHeader "H") (decode <$> getBody), where getHeader and
getBody are functions in the new handler monad (/class). (This isn't quite
right, since decoding failures need to be handled).
Though as I mentioned before, since for servant at least in one direction
it'd be a conversion rather than direct usage of the new handler, and since
we can already convert any servant handler plus appropriate Proxy into an
Application, and can use any Application as a handler, for us it'd be a lot
easier to just use Application. As far as I can tell, this is also true in
a couple of other frameworks. Indeed, one of the great things about the
Application signature, in my opinion, is that it works well both as the
signature for an entire Application and for a handler (that gets a modified
request). The only problem we've come across with that idea is that the
type of failure of the handler is opaque to the outer framework - so e.g.,
there's no easy way to tell whether re-routing needs to be triggered
because the handler failed to match. This, however, would still be a
problem in the model mentioned above. Having something like Application,
but with return type IO (Either ReroutePlz ResponseReceived), would likely
suffice (as would settling on an exception type).
On Thu, Oct 22, 2015 at 2:00 PM, <web-devel-request(a)haskell.org> wrote:
> Send web-devel mailing list submissions to
> web-devel(a)haskell.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel
> or, via email, send a message with subject or body 'help' to
> web-devel-request(a)haskell.org
>
> You can reach the person managing the list at
> web-devel-owner(a)haskell.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of web-devel digest..."
>
>
> Today's Topics:
>
> 1. More collaboration in web development (Michael Snoyman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 22 Oct 2015 08:13:31 +0300
> From: Michael Snoyman <michael(a)snoyman.com>
> To: web-devel <web-devel(a)haskell.org>, haskell-wai(a)googlegroups.com,
> "yesodweb(a)googlegroups.com" <yesodweb(a)googlegroups.com>
> Subject: [web-devel] More collaboration in web development
> Message-ID:
> <CAKA2JgLpqbOiHVY+vH4vdtUjvY7O-Mb7e2x+ms=B1b=
> NFqA-+g(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I originally kicked this off as an email to the maintainers of some of the
> other WAI web frameworks. After some initial brainstorming and some broad
> consensus to find some more shared common ground, we decided to open this
> up to a broader discussion.
>
> I think the primary forum for this discussion will likely be the web-devel
> mailing list, though I'm cross-posting to haskell-wai and yesodweb as well
> for those interested. Please feel free to share with other mailing lists
> also. (We debated whether to use web-devel or haskell-wai for this
> discussion and didn't come to a decision, I'm fine moving it elsewhere.)
>
> Based on the discussion, it seems like our best next step will be putting
> together a package containing some form of a Handler monad that could be
> shared by multiple web frameworks, hopefully making it easier to write code
> that can move between various frameworks. By contrast, we also seem to be
> in agreement that the high level routing code will end up being
> framework-specific, though we may be able to share some common low-level
> Trie-based dispatch code.
>
> I'll leave it to other participants to restate points they made in the
> initial private discussion.
>
> * * *
>
> Hi all,
>
> When I was in San Francisco a few months ago, Greg and I discussed the
> state of Haskell web development. It's clear that there's a lot of great
> stuff going on. Both of us have a strong desire to find as much common
> ground for all web framework authors to work on as possible, without
> detracting from meaningful distinctions between the various frameworks.
>
> Greg and I have discussed this point off and on for the past few months,
> and haven't come up with very many concrete ideas. The recent work on
> http-api-data[1] would be one possible example of collaboration. Other
> possible ideas that Greg and I brainstormed were some kind of shared
> library for efficient dispatch (that could be used under the surface for
> the various high-level interface different libraries already provide), or
> some kind of a common Handler-like monad (which from what I've seen many
> people seem to reimplement all over the place). Some concrete benefits we
> can see from this:
>
> * Previously, Persistent users were complaining that their types did not
> serialize in servant. http-api-data addresses this.
> * A common Handler would allow a higher layer abstraction for web apps,
> much like WAI provides at a low level. With something like that, sharing
> code like authentication logic becomes a reality
> * We already have precedence for other such shared libraries:
> client-session, server-session, cookie, and authenticate, as a few
> examples.
>
> These are just ideas to kick off some thoughts, I'm sure some discussion
> could bring out some better ideas. Overall, it seems like we have a lot of
> opportunity to improve the situation for everyone if we focus on such
> collaboration. Having a shared low-level HTTP interface (WAI) has already
> helped this out considerably, I'm hoping there's something else we can do
> in this vein as well.
>
> Michael
>
> [1] http://hackage.haskell.org/package/http-api-data
>
I originally kicked this off as an email to the maintainers of some of the
other WAI web frameworks. After some initial brainstorming and some broad
consensus to find some more shared common ground, we decided to open this
up to a broader discussion.
I think the primary forum for this discussion will likely be the web-devel
mailing list, though I'm cross-posting to haskell-wai and yesodweb as well
for those interested. Please feel free to share with other mailing lists
also. (We debated whether to use web-devel or haskell-wai for this
discussion and didn't come to a decision, I'm fine moving it elsewhere.)
Based on the discussion, it seems like our best next step will be putting
together a package containing some form of a Handler monad that could be
shared by multiple web frameworks, hopefully making it easier to write code
that can move between various frameworks. By contrast, we also seem to be
in agreement that the high level routing code will end up being
framework-specific, though we may be able to share some common low-level
Trie-based dispatch code.
I'll leave it to other participants to restate points they made in the
initial private discussion.
* * *
Hi all,
When I was in San Francisco a few months ago, Greg and I discussed the
state of Haskell web development. It's clear that there's a lot of great
stuff going on. Both of us have a strong desire to find as much common
ground for all web framework authors to work on as possible, without
detracting from meaningful distinctions between the various frameworks.
Greg and I have discussed this point off and on for the past few months,
and haven't come up with very many concrete ideas. The recent work on
http-api-data[1] would be one possible example of collaboration. Other
possible ideas that Greg and I brainstormed were some kind of shared
library for efficient dispatch (that could be used under the surface for
the various high-level interface different libraries already provide), or
some kind of a common Handler-like monad (which from what I've seen many
people seem to reimplement all over the place). Some concrete benefits we
can see from this:
* Previously, Persistent users were complaining that their types did not
serialize in servant. http-api-data addresses this.
* A common Handler would allow a higher layer abstraction for web apps,
much like WAI provides at a low level. With something like that, sharing
code like authentication logic becomes a reality
* We already have precedence for other such shared libraries:
client-session, server-session, cookie, and authenticate, as a few examples.
These are just ideas to kick off some thoughts, I'm sure some discussion
could bring out some better ideas. Overall, it seems like we have a lot of
opportunity to improve the situation for everyone if we focus on such
collaboration. Having a shared low-level HTTP interface (WAI) has already
helped this out considerably, I'm hoping there's something else we can do
in this vein as well.
Michael
[1] http://hackage.haskell.org/package/http-api-data
