Agreed 100%. Let's discuss more in SPDY land. -stephen From: Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>> Date: Tuesday, July 2, 2013 5:15 PM To: Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> Cc: Sam Pullara <spullara@gmail.com<mailto:spullara@gmail.com>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>> Subject: Re: HTTP/2.0 -04 candidate Resent-From: <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>> Resent-Date: Tuesday, July 2, 2013 5:15 PM 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<mailto:martin.thomson@gmail.com>> wrote: On 2 July 2013 12:51, Roberto Peon <grmocg@gmail.com<mailto: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 00:18:48 UTC