Re: HTTP/2 Expression of luke-warm interest: Varnish

Lock in is certainly an issue. There are many features in HTTP/1.0
that remained the way they were because we were already a captive of
the deployed base.

But there are different types of lock in. Deployment at Facebook or
Google would not worry me very much because they are services. They
can move on to a new version of the software as quickly as they rolled
out SPDY.

What would worry me more on the server side is a sizable deployment
based on Apache or IIS. In particular takeup by the Web Hosting
companies.

On the client side, Chrome and firefox auto update, no real concern
there, Safari on an iphone 3 does not. So game over.


I would suggest though that the WG not commit to backwards
compatibility with SPDY. Instead I would argue for 'dont break without
a good purpose'.


On Mon, Jul 16, 2012 at 4:58 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> We may want to add to the requirements the definition of a "minimal implementation", such that supports only one concurrent stream, no server push, and default values for all tweakable parameters. Ideally we could test if such an implementation can be programmed in a day using a basic TCP library (for extra credit use just C and libC)
>
> Yoav
>
> On Jul 16, 2012, at 9:55 AM, Grahame Grieve wrote:
>
>> +1
>>
>> I'm just part of the long tail of http implementers. I don't
>> represent any large installed base, I've just written a few
>> http servers and clients because it's easy. One of the
>> reasons for the success of http/1.x is because you can
>> knock out a working server in a day.
>>
>> All the proposals here seem very far from that. "Major
>> Web Companies lock down the web" seems more apt
>> as an inflammatory headline.. but perhaps the easy
>> problems have been solved easily, and only the hard
>> ones are left, and a two-speed web is the right way to go?
>>
>> But it would be a shame to provide no cleaner simple http.
>>
>> So +1 for defining the goals.
>>
>> Grahame
>
>



-- 
Website: http://hallambaker.com/

Received on Monday, 16 July 2012 12:00:35 UTC