Re: jar protocol (was: ZIP archive API?)

On Tue, May 7, 2013 at 7:29 AM, Robin Berjon <robin@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

Received on Tuesday, 7 May 2013 18:58:08 UTC