[web-devel] Proposal: http-types

[Christian Maeder]

Am 02.02.2011 22:34, schrieb 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",

Similar discussions come up again and again.

http://hackage.haskell.org/packages/archive/HTTP/4000.1.1/doc/html/Network-HTTP-Headers.html
even contains a comment
"Encoding HTTP header names differently, as Strings perhaps, is an
equally fine choice..no decidedly clear winner"

Network.HTTP.Base.RequestMethod is a similar data type.

My own conclusion is: avoid as many variants as possible, otherwise
you'll get lots of repetitions of similar code. A single variant
wrapping a String or ByteString is the best for uniform treatment (i.e.
just for implementing show).

You loose (possibly faster and shorter) pattern matching, but I think it
is just as good to use predefined constants and "==" for comparisons.

Cheers Christian

> 
> 2011/2/2 Michael Snoyman
> <michael-cq0OxgmGHj5BDgjK7y7TUQ at public.gmane.org
> <mailto: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-gM/Ye1E23mwN+BqQ9rBEUg at public.gmane.org
>     <mailto: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-cq0OxgmGHj5BDgjK7y7TUQ at public.gmane.org
>     <mailto:michael-cq0OxgmGHj5BDgjK7y7TUQ at public.gmane.org>>
>     >>
>     >> 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
>     <mailto:aristidb-gM/Ye1E23mwN+BqQ9rBEUg at public.gmane.org>> 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-cq0OxgmGHj5BDgjK7y7TUQ at public.gmane.org
>     <mailto:michael at snoyman.com>>
>     >> >>
>     >> >> On Wed, Feb 2, 2011 at 2:50 PM, Aristid Breitkreuz
>     >> >> <aristidb at googlemail.com
>     <mailto:aristidb-gM/Ye1E23mwN+BqQ9rBEUg at public.gmane.org>> wrote:
>     >> >> > I agree with most things.
>     >> >> >
>     >> >> > 2011/2/2 Michael Snoyman
>     <michael-cq0OxgmGHj5BDgjK7y7TUQ at public.gmane.org
>     <mailto:michael-cq0OxgmGHj5BDgjK7y7TUQ at public.gmane.org>>
>     >> >> >>
>     >> >> >> * 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
>     >> >
>     >> >
>     >
>     >
> 
> 
> 
> 
> _______________________________________________
> web-devel mailing list
> web-devel-HC+Z4NTRIlBAfugRpC6u6w at public.gmane.org
> http://www.haskell.org/mailman/listinfo/web-devel