Re: [web-devel] Proposal: http-types

2 Feb 2011


      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 
...
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
 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 
...
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
 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 
...
On Wed, Feb 2, 2011 at 2:50 PM, Aristid Breitkreuz
 wrote:
...
I agree with most things.
2011/2/2 Michael Snoyman 
>
> * 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