[web-devel] Proposal: http-types

[Aristid Breitkreuz]

The current state of http-types:

* Both Method = ByteString and MethodADT (and ADT) exist now, and you can
use whichever you prefer. Conversion functions exist.
* Headers use CIByteString (I named it HttpCIByteString, though.)
* Status is basically like in WAI
* HttpVersion is a record containing two Ints (with bang).
* There are two variants of Query string types: Query and QuerySimple. The
former allows creating Query strings like a&b=c, by setting the value in the
tuple for a to Nothing.

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

> On Thu, Feb 3, 2011 at 6:33 PM, Aristid Breitkreuz
> <aristidb at googlemail.com> wrote:
> > I found your tone disappointing and to some degree upsetting, but I will
> try
> > to stay objective. (I had a few hours to calm down.)
>
> I'm sorry if my email came off as offensive: that was not my
> intention. I have no desire to upset you. I think what you're
> proposing is good. As I said, we're at the nit-pick phase now, where
> we get to pick apart tiny little details of proposals to everyone's
> mutual annoyance. For prior art, see the discussion regarding the text
> package. </ducks>
>

I'm sorry, too. I'm really bad at controlling my emotions.


>  > 2011/2/3 Michael Snoyman <michael at snoyman.com>
> >>
> >> Maybe I should have been more conservative in my previous comments:
> >> assuming that this http-types package is not vastly different than
> >> what I'm already using I can support it. I have no intention of
> >> breaking API compatibility for no reason. Neither change you've
> >> mentioned so far (Method and ditching CIByteString) seems like a wise
> >> move to me.
> >
> > First of all, it is simply not possible to avoid API breakage: WAI is not
> > the only relevant package, even YOUR OWN package http-enumerator uses
> > different types. Given that you break APIs almost regularly, I think you
> > could find a way to do this.
>
> I only break APIs when I think it is beneficial. That is the question
> on the table: are your proposals going to make WAI better, and is the
> "good differential" great enough to warrant a breaking change.
>

Of course.


>  > Secondly, please provide reasons for why said things are not wise moves.
> If
> > you want to command me, pay me or do this yourself, but given that you do
> > neither, I demand explanations, reasoning and debate.
>
> Firstly, let's not get into the "command me" thing. Remember, you're
> actually asking *me* to change my packages. You should feel free to
> make your package however you see fit. However, if I think it's not
> beneficial to WAI and http-enumerator users, I won't support it. Point
> in case: you can implement Method however you want, but I won't
> necessarily use it.
>


Just like not everybody in the server space is going to use WAI? :-P


>  > I did not even claim that I want to ditch CIByteString, just that I am
> > unsure how to proceed with it.
>
> OK. I think putting it back on the table is a "step backwards": the
> decision to add CIByteString was a suggestion from Snap (Greg Collins)
> that has a lot of merit, both semantically and performance wise, and I
> don't really want to rehash the discussion. If we must rehash, then we
> will, but please at least look up the old discussions first. Claiming
> CIByteString doesn't have "buy-in" is not really true.
>

Well, I joined the mailing list only recently (on your suggestion), and do
not know which discussions you mean. It would be nice if you could provide
pointers to these discussions.

But I have implemented CIByteString now, and see the merit now.


> > Note that you yourself do not even use CIByteString consistently: You use
> it
> > for the header names in WAI, but not for Method, and not at all in
> > http-enumerator.
>
> Universal usage is not the same as consistent usage. To quote the HTTP
> spec (5.1.1), "The method is case-sensitive." Therefore, it wouldn't
> make sense to use CIByteString for Method. And i'm not sure why you
> think I don't use CIByteString in http-enumerator: look at the
> definition of Headers[1].
>

Wow, I made two mistakes in a row: I thought HTTP methods are
case-insensitive (but I already learned from Gregory Collins that this is
not the case), and I did not notice the fact that Headers now uses
CIByteString. In http-enumerator 0.2.1.5, Headers used ByteString for the
name, but this obviously changed, and I to my shame did not notice it.


> I really did think I addressed why I did not like your proposed change
> to method: it breaks pattern matching. All the rules in the world
> about how you *should* use the datatype doesn't change that. Hiding
> the export of the OtherMethod constructor helps, but this introduces
> so many special cases as opposed to just using a ByteString. I
> personally don't see matching POST as enough better than "POST" to
> warrant the extra overhead of the calls to byteStringToMethod and
> methodToByteString. And I have good reason for this: I've implemented
> both approaches in WAI, and find the current one superior.


Well, even before the OtherMethod constructor was hidden, it was considered
invalid to use it on standard methods.


> As for the issue of not including CIByteString, I think it should be
> obvious why I would be opposed: CIByteString is the more appropriate
> data type for case-insensitive datatypes.
>

It is not flawless: It breaks for all non-ASCII/non-Latin1 encodings. This
is probably not a problem in this case, however.


Aristid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110203/b7d9ab90/attachment-0001.htm>