[web-devel] Proposal: http-types

[Michael Snoyman]

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>

> 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.

> 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/Network-HTTP-Enumerator.html#t:Headers