Re: HTTP/2.0 -04 candidate

If it can wait until tomorrow morning, that would be good.  I've got
fixes for the last issues from Alexey and Hasan inbound, but I'm not
in a position to do anything significant at home since my machine
died.

I talked to Mark earlier and it might be that we miss the July 4
deadline, to allow folks a little more time to assimilate these edits.

(If this can wait another 12 hours, I can excise the associated stream
reset bug at the same time.)

On 2 July 2013 18:23, James M Snell <jasnell@gmail.com> wrote:
> +1
>
> On Jul 2, 2013 5:48 PM, "Jeff Pinner" <jpinner@twitter.com> wrote:
>>
>> partial ThreadJack:
>>
>> Can we get a draft-unicorn-httpbis-http2-01 published with all the changes
>> that were merged over the past day? Don't want to burden but given we have 2
>> days until the -04 release I'm hoping the slightly faster iteration pace is
>> ok.
>>
>>
>> On Tue, Jul 2, 2013 at 5:18 PM, William Chan (陈智昌) <willchan@chromium.org>
>> wrote:
>>>
>>> I'm not as concerned about this, because I'm optimistically thinking more
>>> long-term and envisioning a world where domain sharding hacks are a thing of
>>> the past. Yeah, we're a long ways off still. But I'm still beating the drums
>>> as long as I can to get people to deprecate those hacks.
>>>
>>>
>>> On Tue, Jul 2, 2013 at 5:15 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>>>
>>>> Actually in this case I'm worried about latency more than the cost of
>>>> additional connections!
>>>> I don't want to spend the extra RTs necessary to set up additional (and
>>>> not that useful) SSL connections if it is avoidable.
>>>> Requiring that would make HTTP/2.0 significantly slower than HTTP/1 in
>>>> many cases where domain sharding has been used. :(
>>>> -=R
>>>>
>>>>
>>>> On Tue, Jul 2, 2013 at 12:55 PM, Martin Thomson
>>>> <martin.thomson@gmail.com> wrote:
>>>>>
>>>>> On 2 July 2013 12:51, Roberto Peon <grmocg@gmail.com> wrote:
>>>>> > Yes, there are cases where the mechanism spec'd in SPDY today is
>>>>> > suboptimal.
>>>>> > That seems like a poor reason to reject it, however, when the
>>>>> > alternative is
>>>>> > guaranteed suboptimality.
>>>>>
>>>>> That's true, the coalescing that SPDY does won't work 100% of the
>>>>> time, but the times where it does work will make (most) things better.
>>>>>  If by better you mean fewer connections - and we're fairly sure that
>>>>> is actually better.
>>>>
>>>>
>>>
>>
>

Received on Wednesday, 3 July 2013 03:20:14 UTC