You essentially forced me to do this. ;-)<div><br></div><div>So here it is, my initial version of http-types: <meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="https://github.com/aristidb/http-types">https://github.com/aristidb/http-types</a></div>
<div><br></div><div><a href="https://github.com/aristidb/http-types"></a>Only Method is supported for now.</div><div><br></div><div>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.</div>
<div><br></div><div>Please take it apart and criticize! :-)</div><div><br></div><div>If you have implementation ideas, just fork it, or I can add you as a contributor.</div><div><br></div><div><br></div><div>Aristid</div>
<div><br><br><div class="gmail_quote">2011/2/2 Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think there's general consensus that this package would be a Good<br>
Thing(tm), and at the least you'll have my support on it. I'm sure we<br>
can all quibble on details later, but I think the best thing now would<br>
be to have some actual code to look at.<br>
<br>
Aristid, I'm assuming (hoping) you were volunteering to actually write<br>
and maintain this package, is that correct? I would recommend you get<br>
a project started (Github, BitBucket, PatchTag, wherever), getting up<br>
some code and then we can all nit-pick it to death ;).<br>
<br>
Michael<br>
<br>
On Wed, Feb 2, 2011 at 3:45 PM, Aristid Breitkreuz<br>
<div><div></div><div class="h5"><<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>> wrote:<br>
> http-enumerator could at least for compatibility support a Request type with<br>
> ByteString. And also a native request type. Or something along these lines.<br>
> The problem is that I want to be able to use a Request type that is<br>
> compatible between multiple client libraries, enabling me to theoretically<br>
> switch implementations without a huge amount of hassle.<br>
><br>
> Aristid<br>
><br>
> 2011/2/2 Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>><br>
>><br>
>> On Wed, Feb 2, 2011 at 2:50 PM, Aristid Breitkreuz<br>
>> <<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>> wrote:<br>
>> > I agree with most things.<br>
>> ><br>
>> > 2011/2/2 Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>><br>
>> >><br>
>> >> * Request and response datatypes themselves. I don't think this makes<br>
>> >> sense to put in http-types: just between WAI and http-enumerator I<br>
>> >> needed different versions of these.<br>
>> ><br>
>> > I think this is where we could derive most value, and it would be good<br>
>> > to<br>
>> > find a way to do it.<br>
>> > Request actually looks pretty similar in WAI as in http-enumerator, but<br>
>> > Response is different. Maybe distinguish between client and server<br>
>> > versions<br>
>> > of Response?<br>
>><br>
>> I'd be very surprised if those two can be meaningfully unified. What<br>
>> do you do about remoteHost and errorHandler? Also, it's more useful to<br>
>> have the request body for http-enumerator be an Enumerator of<br>
>> Builders, as opposed to WAI where we want an Enumerator of<br>
>> ByteStrings.<br>
>><br>
>> I have no opposition to *having* a Request type in http-types (or<br>
>> whatever we call it), but I doubt anyone will actually use it, and I<br>
>> wouldn't even want it to include Builder due to the extra dependency.<br>
>><br>
>> Michael<br>
><br>
><br>
</div></div></blockquote></div><br></div>