[web-devel] Proposal: http-types

[Aristid Breitkreuz]

This is not a problem because constructing OtherMethod "POST" is forbidden
and will/must never happen. byteStringToMethod will always construct POST,
and not OtherMethod "POST",


2011/2/2 Michael Snoyman <michael at snoyman.com>

> Originally WAI *did* use an ADT. However, someone (I *think* Jeremy
> Shaw, I'm not sure) pointed out that pattern matching is in fact
> broken here:
>
> case OtherMethod POST of
>    POST -> putStrLn "Will not get called"
>
> Also, with your implementation
>
> POST /= OtherMethod "POST"
>
> Michael
>
> On Wed, Feb 2, 2011 at 11:12 PM, Aristid Breitkreuz
> <aristidb at googlemail.com> wrote:
> > You essentially forced me to do this. ;-)
> > So here it is, my initial version of
> > http-types: https://github.com/aristidb/http-types
> > Only Method is supported for now.
> > I deliberately chose to make it an ADT for type safety reasons. This is
> to
> > enable developers to write case x of POST -> ..., and the compiler will
> find
> > if they accidentally typed POSTX. However, non-standard methods are also
> > supported via OtherMethod.
> > Please take it apart and criticize! :-)
> > If you have implementation ideas, just fork it, or I can add you as a
> > contributor.
> >
> > Aristid
> >
> > 2011/2/2 Michael Snoyman <michael at snoyman.com>
> >>
> >> I think there's general consensus that this package would be a Good
> >> Thing(tm), and at the least you'll have my support on it. I'm sure we
> >> can all quibble on details later, but I think the best thing now would
> >> be to have some actual code to look at.
> >>
> >> Aristid, I'm assuming (hoping) you were volunteering to actually write
> >> and maintain this package, is that correct? I would recommend you get
> >> a project started (Github, BitBucket, PatchTag, wherever), getting up
> >> some code and then we can all nit-pick it to death ;).
> >>
> >> Michael
> >>
> >> On Wed, Feb 2, 2011 at 3:45 PM, Aristid Breitkreuz
> >> <aristidb at googlemail.com> wrote:
> >> > http-enumerator could at least for compatibility support a Request
> type
> >> > with
> >> > ByteString. And also a native request type. Or something along these
> >> > lines.
> >> > The problem is that I want to be able to use a Request type that is
> >> > compatible between multiple client libraries, enabling me to
> >> > theoretically
> >> > switch implementations without a huge amount of hassle.
> >> >
> >> > Aristid
> >> >
> >> > 2011/2/2 Michael Snoyman <michael at snoyman.com>
> >> >>
> >> >> On Wed, Feb 2, 2011 at 2:50 PM, Aristid Breitkreuz
> >> >> <aristidb at googlemail.com> wrote:
> >> >> > I agree with most things.
> >> >> >
> >> >> > 2011/2/2 Michael Snoyman <michael at snoyman.com>
> >> >> >>
> >> >> >> * Request and response datatypes themselves. I don't think this
> >> >> >> makes
> >> >> >> sense to put in http-types: just between WAI and http-enumerator I
> >> >> >> needed different versions of these.
> >> >> >
> >> >> > I think this is where we could derive most value, and it would be
> >> >> > good
> >> >> > to
> >> >> > find a way to do it.
> >> >> > Request actually looks pretty similar in WAI as in http-enumerator,
> >> >> > but
> >> >> > Response is different. Maybe distinguish between client and server
> >> >> > versions
> >> >> > of Response?
> >> >>
> >> >> I'd be very surprised if those two can be meaningfully unified. What
> >> >> do you do about remoteHost and errorHandler? Also, it's more useful
> to
> >> >> have the request body for http-enumerator be an Enumerator of
> >> >> Builders, as opposed to WAI where we want an Enumerator of
> >> >> ByteStrings.
> >> >>
> >> >> I have no opposition to *having* a Request type in http-types (or
> >> >> whatever we call it), but I doubt anyone will actually use it, and I
> >> >> wouldn't even want it to include Builder due to the extra dependency.
> >> >>
> >> >> Michael
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110202/94b0cb6b/attachment.htm>