[web-devel] Proposal: http-types
michael at snoyman.com
Thu Feb 3 18:10:03 CET 2011
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
> 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
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.
>> 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
> 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.
More information about the web-devel