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