Re: jar protocol (was: ZIP archive API?)
This seems very related to how prefixes/terms are expanded to IRIs in JSON-LD - see http://www.w3.org/TR/json-ld/#iris The JSON-LD approach is more like registering new local protocols, as they look like URIs. If we tried that out, then: link rel=bundle href=/bundle.zip anchor=b2 / would mean that a href=b2:fred/hello.txt would resolve to fred/hello.txt within bundle.zip. The difference with Robin's proposal defines a new relative prefix - almost like UNIX/Linux can let you mount /home/fred to a different partition than /home - and therefore has this nice HTTP fall-back. You won't have to worry about someone else defining the b2 protocol, as you operate within your own URI namespace. One downside with not having a URI scheme is that you need to propagate the link bindings in any document that needs it - which is probably OK, not very different from how RDF Turtle uses @prefix and XML uses xmlns:fred =. On 7 May 2013 21:31, David Sheets kosmo...@gmail.com wrote: On Tue, May 7, 2013 at 3:29 PM, Robin Berjon ro...@w3.org wrote: On 06/05/2013 20:42 , Jonas Sicking wrote: The only things that implementations can do that JS can't is: * Implement new protocols. I definitely agree that we should specify a jar: or archive: protocol, but that's orthogonal to whether we need an API. Have you looked at just reusing JAR for this (given that you support it in some form already)? I wonder how well it works. Off the top of my head I see at least two issues: • Its manifest format has lots of useless stuff, and is missing some things we would likely want (like MIME type mapping). • It requires its own URI scheme, which means that there is essentially no transition strategy for content: you can only start using it when everyone is (or you have to do UA detection). I wonder if we couldn't have a mechanism that would not require a separate URI scheme. Just throwing this against the wall, might be daft: We add a new link relationship: bundle (archive is taken, bikeshed later). The href points to the archive, and there can be as many as needed. The resolved absolute URL for this is added to a list of bundles (there is no requirement on when this gets fetched, UAs can do so immediately or on first use depending on what they wish to optimise for). After that, whenever there is a fetch for a resource the URL of which is a prefix match for this bundle the content is obtained from the bundle. This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut A UA supporting this would grab the bundle, then extract the image from it. A UA not supporting this would do nothing with the link, but would issue a request for /bundle.wrap/img/dahut.png. It is then fairly easy on the server side to be able to detect that it's a wrapped resource and serve it from inside the bundle (or whatever local convention it wants to adopt that allows it to cater to both — in any case it's trivial). This means no URL scheme to be supported by everyone, no nested URL scheme the way JAR does it (which is quite distasteful), no messing with escaping ! in paths, etc. WDYT? This is really cool! Most servers already contain support for this in the form of index files. If you do link rel=bundle href=bundle.wrap/ / and set your server's file directory resolver to match index.zip, you don't need any special server-side extraction or handling: just extract the archive root as sibling to index.zip when you deploy! Additionally, this piggybacks application resource caching on top of HTTP caching. One quirk of this scheme (ha) is its notion of root path. With this path pattern match, the subresources in the archive exist in the domain's single top-level path structure. This means that for archives to be fully self-contained they must only use relative references that do not escape the archive root. Of course, this is also a feature when the containment of the archive is not a concern. How does directory resolution inside a bundle work? i.e. resolve bundle.wrap/dir/ ? It seems like this (listing) is a key feature of the API that was being discussed. I support a JSON object without a well-known name, personally. Can we use Link: bundle.wrap/; REL=bundle for generic resources? Does a href=bundle.wrap/page.htmlGo!/a make a server request or load from the bundle? Do bundle requests Accept archive media types? Do generic requests (e.g. address bar) Accept archive media types? What if I do link rel=bundle href= / ? Will this page be re-requested Accept-ing archive media types? Could bundles be entirely prefixed based? What does link rel=bundle href=bundle.wrap# / with img src=bundle.wrap#images/dahut.png / !-- or is it
jar protocol (was: ZIP archive API?)
On 06/05/2013 20:42 , Jonas Sicking wrote: The only things that implementations can do that JS can't is: * Implement new protocols. I definitely agree that we should specify a jar: or archive: protocol, but that's orthogonal to whether we need an API. Have you looked at just reusing JAR for this (given that you support it in some form already)? I wonder how well it works. Off the top of my head I see at least two issues: • Its manifest format has lots of useless stuff, and is missing some things we would likely want (like MIME type mapping). • It requires its own URI scheme, which means that there is essentially no transition strategy for content: you can only start using it when everyone is (or you have to do UA detection). I wonder if we couldn't have a mechanism that would not require a separate URI scheme. Just throwing this against the wall, might be daft: We add a new link relationship: bundle (archive is taken, bikeshed later). The href points to the archive, and there can be as many as needed. The resolved absolute URL for this is added to a list of bundles (there is no requirement on when this gets fetched, UAs can do so immediately or on first use depending on what they wish to optimise for). After that, whenever there is a fetch for a resource the URL of which is a prefix match for this bundle the content is obtained from the bundle. This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut A UA supporting this would grab the bundle, then extract the image from it. A UA not supporting this would do nothing with the link, but would issue a request for /bundle.wrap/img/dahut.png. It is then fairly easy on the server side to be able to detect that it's a wrapped resource and serve it from inside the bundle (or whatever local convention it wants to adopt that allows it to cater to both — in any case it's trivial). This means no URL scheme to be supported by everyone, no nested URL scheme the way JAR does it (which is quite distasteful), no messing with escaping ! in paths, etc. WDYT? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote: This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut You need a new URL scheme here. Otherwise the URL will be parsed relative to the node's base URL. -- http://annevankesteren.nl/
Re: jar protocol (was: ZIP archive API?)
* Anne van Kesteren wrote: On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote: This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut You need a new URL scheme here. Otherwise the URL will be parsed relative to the node's base URL. Robin seems to address that in the parts of his mail you didn't quote. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 11:34 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Robin seems to address that in the parts of his mail you didn't quote. My bad :-( Have to say it does seem quite elegant. And has great fallback (if implemented on the server). -- http://annevankesteren.nl/
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote: On 06/05/2013 20:42 , Jonas Sicking wrote: The only things that implementations can do that JS can't is: * Implement new protocols. I definitely agree that we should specify a jar: or archive: protocol, but that's orthogonal to whether we need an API. Have you looked at just reusing JAR for this (given that you support it in some form already)? I wonder how well it works. Off the top of my head I see at least two issues: • Its manifest format has lots of useless stuff, and is missing some things we would likely want (like MIME type mapping). • It requires its own URI scheme, which means that there is essentially no transition strategy for content: you can only start using it when everyone is (or you have to do UA detection). I wonder if we couldn't have a mechanism that would not require a separate URI scheme. Just throwing this against the wall, might be daft: We add a new link relationship: bundle (archive is taken, bikeshed later). The href points to the archive, and there can be as many as needed. The resolved absolute URL for this is added to a list of bundles (there is no requirement on when this gets fetched, UAs can do so immediately or on first use depending on what they wish to optimise for). After that, whenever there is a fetch for a resource the URL of which is a prefix match for this bundle the content is obtained from the bundle. This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut A UA supporting this would grab the bundle, then extract the image from it. A UA not supporting this would do nothing with the link, but would issue a request for /bundle.wrap/img/dahut.png. It is then fairly easy on the server side to be able to detect that it's a wrapped resource and serve it from inside the bundle (or whatever local convention it wants to adopt that allows it to cater to both — in any case it's trivial). This means no URL scheme to be supported by everyone, no nested URL scheme the way JAR does it (which is quite distasteful), no messing with escaping ! in paths, etc. WDYT? Will this let us support reading things from blob: URLs where the Blob contains a zip file? I.e. what Gecko would support as jar:blob:abc-123!/img/foo.jpg. Also note that while we're using jar as scheme name, it's simply just zip support. None of the other pieces of the jar spec is used. / Jonas
Re: jar protocol (was: ZIP archive API?)
* Robin Berjon wrote: I wonder if we couldn't have a mechanism that would not require a separate URI scheme. Just throwing this against the wall, might be daft: We add a new link relationship: bundle (archive is taken, bikeshed later). The href points to the archive, and there can be as many as needed. The resolved absolute URL for this is added to a list of bundles (there is no requirement on when this gets fetched, UAs can do so immediately or on first use depending on what they wish to optimise for). After that, whenever there is a fetch for a resource the URL of which is a prefix match for this bundle the content is obtained from the bundle. There have been many proposals over the years that would allow for some- thing like this, http://www.w3.org/TR/DataCache/ for instance, allows to intercept certain requests to aid in supporting offline applications, and `registerProtocolHandler` combined with `web+`-schemes go into a si- milar direction. Those seem more worthwhile to explore to me than your one-trick-strawman. Also, it is not clear to me that avoiding a special scheme is a useful design constraint (not to mention that bundling is something the com- puter is supposed to do for me, so I would want to get that out of my face). But I can see value in a more generic feature that allows me to implement and reference IO objects as I see fit, which would provide for bundling features. This means no URL scheme to be supported by everyone, [...] Well, `rel='bundle'` would have to be supported by everyone, because past critical mass there would be too many nobody noticed the fallback is not working until now cases, so that seems rather uninteresting in the longer term. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 9:29 AM, Robin Berjon ro...@w3.org wrote: Have you looked at just reusing JAR for this (given that you support it in some form already)? I wonder how well it works. Off the top of my head I see at least two issues: JARs are just ZIPs with Java metadata. We don't need metadata, so plain ZIPs are enough. link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.**png alt=a dahut This depends on a document, so it wouldn't work in workers unless we add a second API to register them in script. -- Glenn Maynard
