[web-devel] Proposal: http-types

[Michael Snoyman]

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
>> >
>> >
>
>