Regarding fallback: - when zip files are blocked by a firewall - when light browsers don't have enough resource to load a big zip file - when browser don't support a specific package format (jar, tgz...)
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"> ... <img src="pack:pack1/graph1.png"> The browser could probably try an alternative url, per resource originally meant to be packed, like GET /pack1.zip/graph1.png Accept: image/* It would be up to the server using packages to make this alternative link available And it would still work with media fragments using the query form GET /pack1.zip/graph1.png?xywh=160,120,320,240 On 29 août 2013, at 12:02, Alexandre Morgaut wrote: > Such concept make me think to something I already saw long time ago: > - http://limi.net/articles/resource-packages/ > - > http://unscriptable.com/2010/08/03/firefoxs-proposed-resource-packages-spec-sucks/ > - http://people.mozilla.com/~jlebar/respkg/ > > I liked the possibility to declare link resources to refer to, you were > potentially able to load multiple archives depending of the layer logic of > the app/site the same way you would do with image sprites or concatenated JS > files > ex: > - framework layer > - app / site layer > - interface / page layer > Using the "packages" attribute made in my opinion this granularity still > possible but harder > With <link> tags you were able to put distinct ones in HTML templates while > you can't with the "packages" attribute > > > Regarding internal links there is an existing scheme used in MHTML: "cid:" > and "mid:" > - http://tools.ietf.org/html/rfc2557 > - http://tools.ietf.org/html/rfc2392 > (note: a scheme to consider for the URL API?) > But they may not be the best one to use > > I looked also at the "res:" microsoft scheme but their use of "#" to target > sub resource is an issue preventing good support of media fragments > It also has a bad history with security issues > - http://msdn.microsoft.com/en-us/library/aa767740(v=vs.85).aspx > - http://support.microsoft.com/kb/220830 > - http://ha.ckers.org/blog/20070721/res-protocol-local-file-enumeration/ > > Something I'd find interesting would be > > have a "package" or "resources" link type able to link to few standard > archive formats (zip, jar, tar, tgz...) to be decided (gz already standard in > HTTP) > > ex: > > <link id="pack1" rel="package" src="/pack1.zip" type="application/zip" > title="My app global resources"> > > and then be able to refer to any of the package file via the link tag id > using a global package specific scheme > > ex: > <img src="pack:pack1/graph1.png"> > > Media fragments should still work on such URL but it might be required, or at > least recommended, to specify the MIME type in the tag as it won't be > provided by HTTP. Of course the browser can still automatically define it > from the extension if not specified as the HTTP server does > > <img src="pack:pack1/graph1.png#xywh=160,120,320,240"> > > or a bit safer > > <img src="pack:pack1/graph1.png#xywh=160,120,320,240" type="image/png"> > > If we don't to create a new scheme, > - the "cid:" one may be used considering the Content-ID as defined by the > link id + the sub resource path > > <img src="cid:pack1/graph1.png"> > > - the "mid:" one may be used considering the Message-ID as defined by the > link id and the Content-ID as the sub resource path > > <img src="mid:pack1/graph1.png"> > > It would mean creating a RFC updating the 2392 RFC instead of creating a new > one from scratch > -> an issue being that "cid:" and "mid: "don't expect fragments and I think > that nothing prevent a Content-ID to contain a "#" in a MIME mail or MHTML > file, so the URL API may have little more complex check to do to correctly > fill the URL object properties (current context, existing package link in > header...) > > For such solution the link "rel" attribute value and the URL scheme name > should meet a global adoption. I think that we should try to make them much > related to each other if possible > > > Another point I found interesting to think of: > > The same way debuggers like Web Inspector allow to inspect cookies and web > storages, they should be able to list packages, list them by id used as keys > and show: > - their size > - their archive format > - their description (from the "title" attribute) > - the list of their files (preferably supporting internal folder hierarchy) > > > > > On 28 août 2013, at 15:32, Anne van Kesteren wrote: > >> A couple of us have been toying around with the idea of making zip >> archives first-class citizens on the web. What we want to support: >> >> * Group a bunch of JavaScript files together in a single resource and >> refer to them individually for upcoming JavaScript modules. >> * Package a bunch of related resources together for a game or >> applications (e.g. icons). >> * Support self-contained packages, like Flash-ads or Flash-based games. >> >> Using zip archives for this makes sense as it has broad tooling >> support. To lower adoption cost no special configuration should be >> needed. Existing zip archives should be able to fit right in. >> >> >> The above means we need URLs for zip archives. That is: >> >> <img src="... test.zip ... image.gif"> >> >> should work. As well as >> >> <iframe src="... test.zip ... test.html"></iframe> >> >> and test.html should be able to contain URLs that reference other >> resources inside the zip archive. >> >> >> We have thought of three approaches for zip URL design thus far: >> >> * Using a sub-scheme (zip) with a zip-path (after !): >> zip:http://www.example.org/zip!image.gif >> * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif >> * Using media fragments: http://www.example.org/zip#path=image.gif >> >> High-level drawbacks: >> >> * Sub-scheme: requires changing the URL syntax with both sub-scheme >> and zip-path. >> * Zip-path: requires changing the URL syntax. >> * Fragments: fail to work well for URLs relative to a zip archive. >> >> Fragments are conceptually the cleanest as the only part of a URL >> that's supposed to depend on the Content-Type is the fragment. >> However, if you want to link to an ID inside an HTML resource you'd >> have to do #path=test.html&id=test which would require adding >> knowledge to the HTML resource that it is contained in a zip archive >> and have special processing based on that. And not just HTML, same >> goes for CSS or JavaScript. >> >> I'm not sure we need to consider sub-scheme if zip-path can work as >> it's more complex and not very well thought out. E.g. imagine >> view-source:zip:http://www.example.org/zip!test.html. (I hope we never >> need to standardize view-source and that it can be restricted to the >> address bar in browsers.) >> >> zip-path makes zip archive packaging by far the easiest. If we use %! >> as separator that would cause a network error in some existing >> browsers (due to an illegal %), which means it's extensible there, >> though not backwards compatible. >> >> We'd adjust the URL parser to build a zip-path once %! is encountered. >> And relative URLs would first look if there's a zip-path and work >> against that, and use path otherwise. >> >> Fetching would always use the path. If there's a zip-path and the >> returned resource is not a zip archive it would cause a network error. >> >> >> As for nested zip archives. Andrea suggested we should support this, >> but that would require zip-path to be a sequence of paths. I think we >> never went to allow relative URLs to escape the top-most zip archive. >> But I suppose we could support in a way that >> >> %!test.zip!test.html >> >> goes one level deeper. And "../image.gif" in test.html looks in the >> enclosing zip. And "../../image.gif" in test.html looks in the >> enclosing zip as well because it cannot ever be relative to the path, >> only the zip-path. >> >> >> -- >> http://annevankesteren.nl/ > Alexandre Morgaut Wakanda Community Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email : alexandre.morg...@4d.com Web : www.4D.com
