Re: HTTP/2.0 -04 candidate

Tomorrow morning is perfect -- thanks for all your hard work!


On Tue, Jul 2, 2013 at 8:19 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

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