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
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
<link rel="bundle" href="bundle.wrap">
<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.
Robin Berjon - http://berjon.com/ - @robinberjon