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 w...@marcosc.com (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
CfC: publish new WD of Shadow DOM; deadline May 11
Dimitri would like to publish a new WD of Shadow DOM and this is a Call for Consensus to do so, using the following version of the spec that is already prepared for publication on May 14: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/publish/shadow/WD-shadow-dom-20130514/index.html Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the _contents_ of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by May 11 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. NOTE: this CfC is unusually short so that this new WD of Shadow DOM can be published on the same day (May 14) some other Web Components specs (e.g. Custom Elements) will be published. If anyone objects to this shortened review period, please speak up. -Thanks, AB
Re: jar protocol
On 10/05/2013 03:23 , Jonas Sicking wrote: On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres 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. 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
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
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: img src='/bundle.zip/img/dahut.jpg' 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: img src='/bundle.zip/img/dahut.jpg' img src='/bundle.zip/img/unicorn.jpg' img src='/bundle.zip/img/chupacabra.jpg' img src='/bundle.zip/img/robin-at-the-beach.jpg' 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
Can you hash out a little bit more how this would work? I'm assuming you mean something like: img src='/bundle.zip/img/dahut.jpg' 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... img src='/products/images/clock.jpg' bundle=//products/images/bundle.zip 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: link rel=bundle name=products href=//products/images/bundle.zip img src='/img/dahut.jpg' bundle=link:products 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
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 ro...@w3.org 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: img src='/bundle.zip/img/dahut.jpg' 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: img src='/bundle.zip/img/dahut.jpg' img src='/bundle.zip/img/unicorn.jpg' img src='/bundle.zip/img/chupacabra.jpg' img src='/bundle.zip/img/robin-at-the-beach.jpg' 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
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... img src='/products/images/clock.jpg' bundle=//products/images/bundle.zip 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: link rel=bundle name=products href=//products/images/bundle.zip img src='/img/dahut.jpg' bundle=link:products 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 link 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 (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
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 link 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
On May 9, 2013 9:03 AM, Robin Berjon ro...@w3.org 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);
$(link rel='bundle').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
