On Mon, Jul 16, 2012 at 12:24 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > In message <CAP+FsNcoyx7= > EfXLezzHGq-3_+BWTwhLQj8dGObvKpSsHMMarg@mail.gmail.com> > , Roberto Peon writes: > > >but you must know about all possible resources that > >the dynamic page will generate at the time you create the bundle. > > Building a zip(-like) archive on the fly has the same complexity > as building the server-push stream, but the benefit of not making > life complex for everybody else. > With a zip-like archive, you'd not be able to interleave delivery, thus you cannot change your mind about what should be pushed (if, for instance, one discovers that multiple things require subresource A and only one thing requires subresource B), the user-agent cannot cancel receipt/delivery of the streams, and so instead of potentially wasting at most a BDP's worth of bytes, we waste potentially the sum of the size of all objects within the zip-like archive. I see a significant loss of flexibility and am unclear on the gain. So, how does a zip-like archive make life easier, and what are the tradeoffs? What am I missing? > But yes, it's not without problems, which is why I think we should > stick to the strict request-response model. > We know that the trend towards higher available bandwidth continues across a broad spectrum of the 'net and we know that the speed of light hasn't appreciably changed. So, basically, we know that what we have today is significantly imperfect in a latency sense and getting worse and worse. We can acknowledge that it is a problem and engineer a solution, or we can decide to not solve this problem, in which case we'll be forcing everyone to inline everything all the time. Bleh. Inlining is easy to mess up and when messed up, can slow down page rendering time horribly. I see a problem which exists today where we can engineer a solution that will allow the infrastructure to do the right thing on behalf of the site developers, which gives much better fine-grained control over which resources arrive in what order (which is important for above-the-fold user experience), and which solves the 'empty pipe' problem that currently exists with HTTP. I'm not in favor of punting on this simply because the problem is difficult. :) -=R > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Received on Monday, 16 July 2012 20:04:13 UTC