Re: Optimizations vs Functionality vs Architecture

On 22.08.2012 12:52, James M Snell wrote:
> On Tue, Aug 21, 2012 at 3:00 PM, Roberto Peon <grmocg@gmail.com> 
> wrote:
>
>>
>>
>> On Tue, Aug 21, 2012 at 1:47 PM, Yoav Nir <ynir@checkpoint.com> 
>> wrote:
>>
>>>
>>> On Aug 21, 2012, at 10:14 PM, Poul-Henning Kamp wrote:
>>> >> We should if it's possible. Suppose HTTP/2.0 looks much like the 
>>> SPDY
>>> draft.
>>> >> How can you ever get a current HTTP/1 server to reply to this?
>>> >
>>> > That's why I've been saying from the start that SPDY was an 
>>> interesting
>>> > prototype, and now we should throw it away, and start from 
>>> scratch,
>>> being
>>> > better informed by what SPDY taught us.
>>>
>>> A requirement for downgrade creates too many restrictions, even if 
>>> we
>>> throw SPDY away. The beginning of a 2.0 connection would have to 
>>> look
>>> enough like 1.x so as to fool existing servers.
>>>
>>>
>> Note that we'll always have to do downgrade-- perhaps someone 
>> deploys a
>> proxy which doesn't speak HTTP/2, or perhaps the site administrator 
>> deploys
>> a different server or load balancer that only speaks HTTP/1.1 when 
>> it used
>> to do HTTP/2.
>> These will happen and must be addressed.
>>
>>
>>> I think we should live with upgrade only, as long as clients can 
>>> cache
>>> the knowledge that a certain server supports 2.0, so that they can 
>>> skip the
>>> upgrade the next time. The extra roundtrip on a first encounter is 
>>> not that
>>> bad.
>>>
>>
>> I disagree-- I want the user to experience the lowest latency 
>> possible for
>> all sites possible whenever possible! :)
>>
>>
> The more I read through this conversation, the more I worry that all 
> this
> talk about zero-latency upgrade negotiation through multiple hops of
> arbitrary 1.1 or 2.0 servers is going to lead to significantly more
> complexity than originally hoped -- and not the acceptable good kind 
> of
> complexity that delivers real benefits in the end.

I'm more positive. Many of these proposed mechanisms are non-starters 
for one reason or another. Meanwhile we are building a good list of 
requirements that the final solution(s) must meet in order to be useful 
adding to the spec.

Amos

Received on Wednesday, 22 August 2012 03:08:24 UTC