- From: Robin Berjon <robin@w3.org>
- Date: Fri, 13 Sep 2013 12:10:47 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Alexandre Morgaut <Alexandre.Morgaut@4d.com>, WHATWG <whatwg@whatwg.org>
On 29/08/2013 14:48 , Anne van Kesteren wrote: > On Thu, Aug 29, 2013 at 1:15 PM, Alexandre Morgaut > <Alexandre.Morgaut@4d.com> wrote: >> In the solution mentioned with <link> tag and a "pack:" like scheme >> >> <link id="pack1" rel="package" src="/pack1.zip" type="application/zip" title="My app global resources"> > > I don't think adding a level of indirection is a good idea. I think > the added complexity is the reason this proposal failed the last time > and I don't see a reason to revive it. Actually, the primary objection I recall from the last round of this was that it did not address the major use case that was being considered then, which was performance. It's a revisit of "Limi Packages" and it would seem that they can 1) be slower than individual files in a fair number of cases and 2) bring between nothing and very little compared to SPDY. Of course, that does not remove the value there is in making Zip first class for reasons other than performance. If we can do it without the above indirection then it clearly is better, but using <link> indirection it is possible to make this work without a new scheme, without changing the URL syntax, and while opening the door to graceful fallback. The basic idea is that you start with this: <link rel="package" href="/foo.zip"> and then every URL in the document (e.g. <img src="/foo.zip/meow.gif">) that's a prefix-match for the link's href gets loaded through the zip. Older browsers will fetch /foo.zip/meow.gif, which the server can trivially detect as an error and handle by sending the content from inside the zip. I would rather we figured this out without <link>, but apart from the indirection I reckon this approach has some nice properties and might work if more direct ones don't. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 13 September 2013 10:11:37 UTC