Need to clarify how this relates to HTTP2
marcoscaceres opened this issue · 9 comments
This document should justify why this would be needed over just using HTTP2 - or why HTTP does not address the use cases.
Agreed. I think the "Efficient Delivery" motivation for this can be dropped; SPDY/HTTP2 meets that use case, and does so without encouraging people to deploy Flash-like "downloadable app" Web sites.
I'm hopeful that the newly created draft at http://w3ctag.github.io/packaging-on-the-web addresses this more sanely and demonstrates the range of ways in which packages can be useful. Feel free to reopen if not.
There are existing and upcoming solutions to these problems. On the performance side, HTTP/2 includes the facility to push multiple representations to clients as the result of a single request. Providing packages is orthogonal to the use of HTTP/2. Developers who cannot yet use HTTP/2 may find that using packages can provide performance benefits through reducing numbers of requests. All developers will benefit from being able to package modules and components in ways that make them easy to deliver and reuse.
I suspect that the group of developers who cannot yet use HTTP/2 has very similar membership to the group of developers who won't be able to update their web servers to respond as specified to the Package: true request header.
It'll be interesting to see if implementations make it possible to use HTTP/2 to deliver multiple packages via the same connection, and what benefits this provides. I'm skeptical about performance benefits, but there are very likely to be conceptual and/or distribution benefits for web packages.
Currently the spec says:
There are existing and upcoming solutions to these problems. On the
performance side, HTTP/2 includes the facility to push multiple
representations to clients as the result of a single request.
Providing packages is orthogonal to the use of HTTP/2. Developers
who cannot yet use HTTP/2 may find that using packages can
provide performance benefits through reducing numbers of requests.
All developers will benefit from being able to package modules and
components in ways that make them easy to deliver and reuse.
Server Push is only one mechanism in HTTP/2 that mitigates the need to concatenate, etc. By far more important is HTTP/2 multiplexing and header compression; once you have them, the overhead of individual requests is much smaller, and there isn't any huge advantage to concatenation, spriting, etc.
I'd really recommend taking all of the performance-specific text out of the introduction; while people may be using concatenation, spriting and similar techniques to work around perf issues in HTTP/1, they're hardly going to use the packaging mechanism you describe as a way of improving perf; that puts us back in a world of download-the-app Flash sites, and that's hardly good practice.
If you want to continue talking about this as a perf mechanism, please fly it by the Web Perf WG to get a sanity check...
P.S. I can't reopen this issue...
(reopening issue for @mnot)
I'd really recommend taking all of the performance-specific text out of the introduction; while people may be using concatenation, spriting and similar techniques to work around perf issues in HTTP/1, they're hardly going to use the packaging mechanism you describe as a way of improving perf; that puts us back in a world of download-the-app Flash sites, and that's hardly good practice.
I can't +1 this hard enough. Bundling files is a performance anti-pattern that was forced on us by the limitations of HTTP/1.1. We are now trying to undo that damage and drive developers towards more granular downloads to improve delivery, execution, cache granularity, etc.
If anything, we should have a big warning up front stating that packaging will result in sub-par performance.
Discussed at NYC and decided to remove mention of performance as a driver for this work.
This work has moved to a different forum.