Hi I am Rajeev and I am leading the SPDY investigation @Yahoo (our investigations have begun fairly recently so I am still catching up and wrapping my head around all things SPDY). Hey - but I have opinions already :-). After my initial analysis of the state of things, I am inclined towards William's proposal (as in we should look at alternative ways to "flatten" content of main pages and explore other client driven approaches and possibly include this as optional extension). For one, this keep things simpler by following the client-drives-it-all paradigm. Push introduces a completely new communication paradigm which needs to be thought about in more detail from various points of view (including the cost/benefit/complexity trade-offs). Several of the points mentioned in this thread (and others on spdy-dev@) seem to be important and seem to be a relative state of immaturity to be ready for an HTTP 2.0 level proposal (as opposed to many other parts of the SPDY proposal on which more detailed thinking seems to have been done). Question : the claims of upto 60% improvement in latency with SPDY (vs plain HTTP) - did those include server push or not ? My guess is not. Cheers, Rajeev On 6/7/12 11:56 AM, Peter Saint-Andre wrote: > On 6/7/12 10:54 AM, Martin Thomson wrote: >> On 7 June 2012 09:43, William Chan (陈智昌)<willchan@chromium.org> wrote: >>> * Google is working on efforts to seriously deploy SPDY server push on our >>> properties. I can't comment further on timeline, but I hope to provide data >>> to guide our discussions, so let's not axe it just yet. >>> * To my knowledge, Amazon is using it in their Silk browser. A proxy that >>> uses server push is a fascinating use case, and it'd be cool to get data on >>> that first. >> I'm with Mike and Gabriel on this one. >> >> It would be nice if HTTP/2.0 discussions could be scoped to exclude >> discussions on new protocol semantics. If you feel especially >> attached to the idea of push, then my preference would be to see a new >> draft on it. > +1 > > /psa > > > > >Received on Thursday, 7 June 2012 17:13:43 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 June 2012 17:13:48 GMT