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

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

...

I found your tone disappointing and to some degree upsetting, but I will

On Thu, Feb 3, 2011 at 6:33 PM, Aristid Breitkreuz wrote: 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

...

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