Re: jar protocol
On May 9, 2013 9:03 AM, "Robin Berjon" wrote:
>
> On 07/05/2013 20:57 , Jonas Sicking wrote:
>>
>> 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.
>
>
> Yeah:
>
> var blob = new Blob(zipContent, { type: "application/bundle" })
> , burl = URL.createObjectURL(blob);
> $("").attr("href", burl).appendTo($("head"));
> someImg.src = burl + "/img/foo.jpg";
>
> It might be a little bit more convoluted than desired. If it's a common
operation we could add a convenience method for it. That could become:
>
> var burl = URL.registerBundle(zipInABlob);
> someImg.src = burl + "/img/foo.jpg";
>
> But I'm not sure that's worth it just yet.
I think this is a question of what the main use cases are.
I'm somewhat concerned that this is turning into something very similar to
"Limi packages". They failed to get any tracktion. In part because in some
cases they actually created worse performance than when not used. In part
they just ended up getting very complicated.
So before heading down this path too far I'd recommend checking on
implementor interest.
/ Jonas
Re: jar protocol
>> I'm not sure it matters, I suppose it depends on: >> >> a) where the link tag will be allowed to live > > > You can use anywhere. It might not be valid, but who cares about > validity :) It works. > Some people :) why does it have to be invalid when it works. Lame, no? > >> b) the effects created by including the same link href multiple times in >> the same doc > > No effect whatsoever beyond wasted resources. > Yeah, if a UA mitigated that somehow it would address this pretty well. It should be cached the second time i suppose, but there has to be overhead in re-treating as a fresh request. Maybe they are smart enough to deal with that already. > -- > Robin Berjon - http://berjon.com/ - @robinberjon -- Brian Kardell :: @briankardell :: hitchjs.com
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: would mean that 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 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 wrote: > On Tue, May 7, 2013 at 3:29 PM, Robin Berjon 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 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: >> >> >> >> and >> >> >> >> 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 > > > > 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: ; REL=bundle > > for generic resources? > > Does > > Go! > > 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 > > > > ? > > Will this page be re-requested Accept-ing archive media types? > > Could bundles be entirely prefixed based? > > What does > > > > with > > > > do? Or > > > > with > > > > ? > > Your approach is very compelling, Robin. What do you think about the > roots and indexes? > > Best wishes, > > David > > -- Stian Soiland-Reyes,
Re: jar protocol
On 10/05/2013 17:13 , Brian Kardell wrote: Still, same kinda idea, could you add an attribute that allowed for it to specify that it is available in a bundle? I'm not suggesting that this is fully thought out, or even necessarily useful, just fleshing out the original question in a potentially more understandable/acceptable way... That's not very DRY! That should be pretty much infinitely back-compatible, and require no special mitigation at the server (including configuration wise which many won't have access to) - just that they share the root concept and don't clash, which I think is implied by the server solution too, right? Well it does require some server mitigation since you need to have the content there twice. It's easy to automate, but no easier than what I had in mind. Psuedo-ish code, bikeshed details, this is just to convey idea: That just sounds more complicated! I don't know if this is wise or useful, but one problem that I run into frequently is that I see pages that mash together content where the author doesn't get to control the head... This can make integration a little harder than I think it should be. Well, if you can't at all control the head, is there any chance that you can really control bundling in any useful fashion anyway? I'm not sure it matters, I suppose it depends on: a) where the link tag will be allowed to live You can use anywhere. It might not be valid, but who cares about validity :) It works. b) the effects created by including the same link href multiple times in the same doc No effect whatsoever beyond wasted resources. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol
I've been looking at some of these alternatives for my RO Bundle specification, which is basically a ZIP file. http://purl.org/wf4ever/ro-bundle/2013-05-10/#absolute-uris I have not yet decided which of these schemes would be used in my approach, which is why the above contains these considerations. I considered both the "zip as a folder" approach - which is nice if you have access to the server and can do magic to actually serve the ZIP file, but in the common case gives misleading 404 errors. If the ZIP is on a domain out of your control, you also run the (quite small) risk that when you mint http://example.com/bundle.zip/fred.jpeg it might actually be a different resource. If the URL to the original ZIP has a query parameter, you are in trouble. The JAR scheme as an URI scheme is also not particularly URI-compliant, it is not hierarchically as it does not have //, so you can't formally resolve relative URIs like "../" within it (and in fact, if you do, you easily climb outside the magic !/ marker) - even java.net.URI gets this wrong because it's an "opaque" URI without //. I actually like the widget URI scheme (which is why I am on this list) - but of course it's not resolvable unless you happen to know which ZIP file contains widget://8191dee8-0b8e-452d-8d64-7706a140185e/. Internally in my application I actually 'cheat' and use an MD5 of the URI to the ZIP file so that I get consistent widget URIs for the same file - but this is a bit dangerous, as the md5 of "file:///tmp/file.zip" would give the same widget URI at different times and on different machines. (Using the SHA1 checksum of the ZIP file itself is quite more reliable, but not an option if the file is to be modified). On 10 May 2013 14:54, Robin Berjon wrote: > Hi Brian, > > > On 10/05/2013 15:32 , Brian Kardell wrote: >> >> Would it be possible (not suggesting this would be the common story) to >> reference a zipped asset directly via the full url, sans a link tag? > > > Can you hash out a little bit more how this would work? I'm assuming you > mean something like: > > > > Without any prior set up on the client to indicate that /bundle.zip is a > bundle. This causes the browser to issue GET /bundle.zip/img/dahut.jpg > > At that point, the server can: > > a) return a 404; > b) extract the image and return that; > c) return bundle.zip with some header information telling the browser that > it's not an image but that the "/bundle.zip" part of the URL matched > something else and it should look inside it for the rest of the path. > > Neither (a) nor (b) are very useful to us. (c) could be made to work, but > it's not exactly elegant. The server would also have to know if the UA > supports (c), and fall back to (b) if not, which means that some signalling > needs to be made in the request. That's also not entirely nice (and it would > have to happen on every request since the browser can't guess). > > It gets particularly nasty when you have this: > > > > > > > The chances are good that the browser would issue several of those requests > before the first one returned with the information telling it to look in the > bundle. That means it would return the bundle several times. Definitely a > loss. > > Or did I misunderstand what you had in mind? > > > -- > Robin Berjon - http://berjon.com/ - @robinberjon > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/
Re: jar protocol
> > Can you hash out a little bit more how this would work? I'm assuming you mean something like: > > > Meh, sorta - but I was missing some context on the mitigation strategies - thanks for filling me in offline. Still, same kinda idea, could you add an attribute that allowed for it to specify that it is available in a bundle? I'm not suggesting that this is fully thought out, or even necessarily useful, just fleshing out the original question in a potentially more understandable/acceptable way... That should be pretty much infinitely back-compatible, and require no special mitigation at the server (including configuration wise which many won't have access to) - just that they share the root concept and don't clash, which I think is implied by the server solution too, right? Old UAs would ignore the unknown bundle attribute and request the src as per usual. New UAs could make sure that an archive was requested only once and serve the file out of the archive. Presumably you could just add support into that attribute for some simple way to indicate a named link too... Psuedo-ish code, bikeshed details, this is just to convey idea: I don't know if this is wise or useful, but one problem that I run into frequently is that I see pages that mash together content where the author doesn't get to control the head... This can make integration a little harder than I think it should be. I'm not sure it matters, I suppose it depends on: a) where the link tag will be allowed to live b) the effects created by including the same link href multiple times in the same doc This might be entirely sidetracking the main conversation, so I don't want to lose that I really like where this is going so far sans any of my questions/comments :)
Re: jar protocol
Hi Brian, On 10/05/2013 15:32 , Brian Kardell wrote: Would it be possible (not suggesting this would be the common story) to reference a zipped asset directly via the full url, sans a link tag? Can you hash out a little bit more how this would work? I'm assuming you mean something like: Without any prior set up on the client to indicate that /bundle.zip is a bundle. This causes the browser to issue GET /bundle.zip/img/dahut.jpg At that point, the server can: a) return a 404; b) extract the image and return that; c) return bundle.zip with some header information telling the browser that it's not an image but that the "/bundle.zip" part of the URL matched something else and it should look inside it for the rest of the path. Neither (a) nor (b) are very useful to us. (c) could be made to work, but it's not exactly elegant. The server would also have to know if the UA supports (c), and fall back to (b) if not, which means that some signalling needs to be made in the request. That's also not entirely nice (and it would have to happen on every request since the browser can't guess). It gets particularly nasty when you have this: The chances are good that the browser would issue several of those requests before the first one returned with the information telling it to look in the bundle. That means it would return the bundle several times. Definitely a loss. Or did I misunderstand what you had in mind? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol
Would it be possible (not suggesting this would be the common story) to reference a zipped asset directly via the full url, sans a link tag?
Re: jar protocol
On 10/05/2013 03:23 , Jonas Sicking wrote: On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres wrote: On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote: How do you figure out media types? Is it just sniffing, or do you have some sort of file extensions mapping as well? Sniffing would probably sufficient. The types on the web are pretty stable. I'd probably hard-code at least a default set of extensions as well. Not sure what gecko does right now. It's been quite a while since I last hacked on Gecko stuff, so if you have a pointer about where to look it's likely to save me some time (I'd like to figure out how it works now). I get a sense that there's interest for this feature, I'll scare up a draft. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol
On Friday, May 10, 2013 at 2:23 AM, Jonas Sicking wrote: > On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres (mailto:w...@marcosc.com)> wrote: > > On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote: > > > How do you figure out media types? Is it just sniffing, or do you have > > > some sort of file extensions mapping as well? > > > > Sniffing would probably sufficient. The types on the web are pretty stable. > > > I'd probably hard-code at least a default set of extensions as well. Sure. In the ol' widget spec, we relied on a "file identification table" to match common file extensions to mime types: http://www.w3.org/TR/widgets/#file-identification-table Worked OK, AFAIK. -- Marcos Caceres
Re: jar protocol
On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres wrote: > On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote: >> How do you figure out media types? Is it just sniffing, or do you have >> some sort of file extensions mapping as well? > > Sniffing would probably sufficient. The types on the web are pretty stable. I'd probably hard-code at least a default set of extensions as well. Not sure what gecko does right now.
Re: jar protocol
On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote: > How do you figure out media types? Is it just sniffing, or do you have > some sort of file extensions mapping as well? Sniffing would probably sufficient. The types on the web are pretty stable. -- Marcos Caceres
Re: jar protocol
On 07/05/2013 22:35 , Bjoern Hoehrmann wrote: 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. I am well aware of this, well acquainted with these proposals, and I certainly hope that NavigationController (which is pretty much the Return of DataCache) will come to fruition. That said I do believe that there is value in addressing common use cases with a common solution, so long as it is cheap enough and well layered. We don't know that yet, but I think it's worth investigating. 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. It's valuable in order to get to the critical mass. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol
On 07/05/2013 20:57 , Jonas Sicking wrote:
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.
Yeah:
var blob = new Blob(zipContent, { type: "application/bundle" })
, burl = URL.createObjectURL(blob);
$("").attr("href", burl).appendTo($("head"));
someImg.src = burl + "/img/foo.jpg";
It might be a little bit more convoluted than desired. If it's a common
operation we could add a convenience method for it. That could become:
var burl = URL.registerBundle(zipInABlob);
someImg.src = burl + "/img/foo.jpg";
But I'm not sure that's worth it just yet.
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.
How do you figure out media types? Is it just sniffing, or do you have
some sort of file extensions mapping as well?
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol
On 08/05/2013 01:39 , Glenn Maynard wrote: On Tue, May 7, 2013 at 9:29 AM, Robin Berjon mailto: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. I'm looking at JARs because Gecko supports them. We certainly don't want the Java metadata, but we might need some metadata (e.g. media type mappings). This depends on a document, so it wouldn't work in workers unless we add a second API to register them in script. This isn't initially for Workers, but as indicated previously in this thread a method might be useful anyway. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol
On 07/05/2013 22:31 , David Sheets wrote: On Tue, May 7, 2013 at 3:29 PM, Robin Berjon wrote: WDYT? This is really cool! Glad you like it :) Most servers already contain support for this in the form of index files. If you do 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! Heh, hadn't thought of that — nice hack! 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. Sorry for being thick but I'm having trouble parsing the above. Would you mind rephrasing? 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. I hadn't thought about directory listing. If the use case is just bundling it's not needed (we just need well-defined behaviour when fetching such paths); but returning something is definitely possible. Keeping in mind that this approach does not intend to replace a potential Zip API (unless there's overwhelming demand for it), do you have use cases for returning a listing of some form? We don't have to decide this right now, I can keep it as an open question for the time being (so no need to rush to UCs). Can we use Link: ; REL=bundle for generic resources? I'm not intimately familiar with RFC 5988, but it would seem logical if it Just Worked. Does Go! make a server request or load from the bundle? That's an open question, but my first instinct would be "no". I'm happy to be convinced otherwise though. Do bundle requests Accept archive media types? Sorry, I'm not sure what you mean. Are you asking about bundles inside bundles? Do generic requests (e.g. address bar) Accept archive media types? You mean typing http://example.org/bundle.wrap/kittens.html? I would expect the browser not to do anything specific there. Which is to say, if the server returns the bundle (ignoring the path info) then the browser would likely prompt to download; if the server returns the HTML then it's just HTML. Or do you mean something different with capitalised Accept? The HTTP header? I would rather leave it out of this if we can ;) What if I do ? Presuming that doesn't resolve to a bundle (which it shouldn't) then it's a failure and no bundle gets added to the list of bundles. Could bundles be entirely prefixed based? Sorry, I'm not sure what you mean here. What does with I would expect the URL to drop fragments, I don't think they make sense in this context. do? Or with The ? isn't really special, so with bundle.wrap?/images/dahut.png it should just work. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 9:29 AM, Robin Berjon 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. > > and > > > 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
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 3:29 PM, Robin Berjon 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 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: > > > > and > > > > 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 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: ; REL=bundle for generic resources? Does Go! 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 ? Will this page be re-requested Accept-ing archive media types? Could bundles be entirely prefixed based? What does with do? Or with ? Your approach is very compelling, Robin. What do you think about the roots and indexes? Best wishes, David
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 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 7:29 AM, Robin Berjon 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 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: > > > > and > > > > 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?)
Top-posting FTW! Smells a bit like declarative navigation controller to me. (No, I don't say that like it's a bad thing, actually). cheers On Tue, 07 May 2013 16:29:49 +0200, Robin Berjon 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 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: and 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? -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 11:34 AM, Bjoern Hoehrmann 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?)
* Anne van Kesteren wrote: >On Tue, May 7, 2013 at 7:29 AM, Robin Berjon 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: >> >> >> >> and >> >> > >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 7:29 AM, Robin Berjon 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: > > > > and > > You need a new URL scheme here. Otherwise the URL will be parsed relative to the node's base URL. -- http://annevankesteren.nl/
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 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: and 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
