On Thu, Feb 3, 2011 at 6:33 PM, Aristid Breitkreuz
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>
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.
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.
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.
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].
It seems prudent to point out that WAI started off closer to the package you're designing now, and after input from others and some experience got to where it is now. I don't want it to take a step backwards.
It is probably irrational, but I take pride in what I do, and I do not like when people call it "a step backwards" without any explanation whatsoever.
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. 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. I'm not completely shutting out any other possibilities, but I'm also going to be honest about my opinions. Do not take any of this personally: nothing is meant as an attack on you or your code. Michael [1] http://hackage.haskell.org/packages/archive/http-enumerator/0.3.1/doc/html/N...