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 http://berjon.com/ contains:

    <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

Reply via email to