Re: Some thoughts on server push and client pull

On Thu, 2012-06-07 at 10:07 -0700, William Chan (陈智昌) wrote:

> 
> I understand the desire to split out server push into a separate
> draft / extension. If we don't have data to support push, then by all
> means we should drop it.

imo it doesn't need to be proven out at the early ID stage. Its totally
fair to take an idea like Push and get some experience with it - and
doing that in the open in a inter-vendor way is better experience (and
that realistically needs an ID). If it harms the implementation rate,
that's a data point right there :)

I'm pessimistic about push mostly because I don't think the upside is
very impressive for it compared to its complexity (especially the
complexity required to address the valid raised concerns). But I'm still
very open minded - and I've got half of a firefox implementation on my
back burner to try and add to the experience-gathering portion of the
process.

Its quite possible that push will create a disincentive to spriting, and
inlining js/css. Doing that would actually have an improved impact on
caching (presuming push can be adapted to caching - which I think it
can), and fine grained resource reuse.. those things have the potential
to be larger net wins for the web than the 1 RTT per page load push
typically yields.


>  The main concern I have is with regards to treating push as an
> optional feature / extension. As many of us have stated repeatedly on
> this mailing list, many things that are optional simply become
> unusable in real, public deployments.
> 
> 
>         
>         --Martin
>

Received on Thursday, 7 June 2012 17:19:36 UTC