Re: ZIP archive API?

On 03.05.13 15:18, "Jonas Sicking" <> wrote:

>On Fri, May 3, 2013 at 12:12 PM, Paul Bakaus <> wrote:
>> From: Florian Bösch <>
>> Date: Fri, 3 May 2013 21:05:17 +0200
>> To: Jonas Sicking <>
>> Cc: Paul Bakaus <>, Anne van Kesteren
>> Webapps WG <>, Charles McCathie Nevile
>> <>, Andrea Marchesini <>
>> Subject: Re: ZIP archive API?
>> It can be implemented by a JS library, but the three reasons to let the
>> browser provide it are Convenience, speed and integration.
>> Convenience is the first reason, since browsers by far and large already
>> have complete bindings to compression algorithms and archive formats,
>> letting the browser simply expose the software it already ships makes
>> sense rather than requiring every JS user to supply his own version.
>> Speed may not matter to much on some platforms, but it matters a great
>> on underpowered devices such as mobiles.
>Show me some numbers to back this up and you'll have me convinced :)
>Remember that on underpowered devices native code is proportionally
>slower too.
>> Integration is where the support for archives goes beyond being an API,
>> where URLs (to link.href, script.src, img.src, iframe.src, audio.src,
>> video.src, css url(""), etc.) could point into an archive. This cannot
>> done in JS.
>> I was going to say exactly  that. I want to be able to have a virtual
>> that I can point to. In my CSS, I want to do something like
>> "archive://assets/foo.png" after I loaded and decompressed the ZIP file
>> JS.
>How does the "assets" part in the example above work? What does it
>mean? Is there some registry here or something?

Actually "assets" was just referring to the package name. So what you're
saying below makes total sense, and is what we want to have. Great stuff!

>> Jonas, I'm intrigued ­ do you see a way this could be done in JS? If so,
>> maybe we should build a sample. I'm still thinking the performance
>>won't be
>> good enough, particular on mobile devices, but let's find out.
>You can actually do this in Gecko already. Any archive that you can
>refer to through a URL, you can also reach into.
>So if you have a .zip file in a Blob, and you generate a blob: URL
>like "blob:123-abc" then you can read the "foo.html" file out of that
>archive by using the URL "jar:blob:123-abc!/foo.html". So far this
>doesn't work with ArrayBuffers since there is no way to have a URL
>that refers to an ArrayBuffer.
>You can even load something from inside a zip file from a server by doing
><img src="jar:!/image.jpg">
>Something like that I definitely agree that we should standardize.
>/ Jonas
>> On Fri, May 3, 2013 at 8:04 PM, Jonas Sicking <> wrote:
>>> The big question we kept running up against at Mozilla is "why couldn't
>>> this simply be implemented as a JS library?"
>>> If performance is the argument we need to back that up with data.
>>> / Jonas
>>> On May 3, 2013 10:51 AM, "Paul Bakaus" <> wrote:
>>>> Hi Anne, Florian,
>>>> I think the first baby step, or MVP, is the unpacking that Florian
>>>> mentions below. I would definitely like to have the API available on
>>>> workers and normal context.
>>>> Thanks,
>>>> Paul
>>>> From: Florian Bösch <>
>>>> Date: Fri, 3 May 2013 14:52:36 +0200
>>>> To: Anne van Kesteren <>
>>>> Cc: Paul Bakaus <>, Charles McCathie Nevile
>>>> <>, public-webapps WG <>,
>>>> Marchesini <>
>>>> Subject: Re: ZIP archive API?
>>>> I'm interested a JS API that does the following:
>>>> Unpacking:
>>>> - Receive an archive from a Dataurl, Blob, URL object, File (as in
>>>> filesystem API) or Arraybuffer
>>>> - List its content and metadata
>>>> - Unpack members to Dataurl, Blob, URL object, File or Arraybuffer
>>>> Packing:
>>>> - Create an archive
>>>> - Put in members passing a Dataurl, Blob, URL object, File or
>>>> - Serialize archive to Dataurl, Blob, URL object, File or Arraybuffer
>>>> To avoid the whole worker/proxy thing and to allow authors to
>>>> choose how they want to handle the data, I'd like to see synchronous
>>>> asynchronous versions of each. I'd make synchronicity an
>>>>argument/flag or
>>>> something to avoid API clutter like packSync, packAsync, writeSync,
>>>> writeAsync, and rather like write(data, callback|boolean).
>>>> - Pythons zipfile API is ok, except the getinfo/setinfo stuff is a bit
>>>> over the top:
>>>> - Pythons tarfile API is less clutered and easier to use:
>>>> - zip.js isn't really usable as it doesn't support the full range of
>>>> types (Dataurl, Blob, URL object, File or Arraybuffer) and for
>>>> operation needs to rely on a worker, which is bothersome to setup:
>>>> My own implementation of the tar format only targets array buffers and
>>>> works synchronously, as in.
>>>> var archive = new TarFile(arraybuffer);
>>>> var memberArrayBuffer = archive.get('filename');
>>>> On Fri, May 3, 2013 at 2:37 PM, Anne van Kesteren <>
>>>> wrote:
>>>>> On Thu, May 2, 2013 at 1:15 AM, Paul Bakaus <>
>>>>> > Still waiting for it as well. I think it'd be very useful to
>>>>> > sets
>>>>> > of assets etc.
>>>>> Do you have anything in particular you'd like to see happen first?
>>>>> It's pretty clear we should expose more here, but as with all things
>>>>> we should do it in baby steps.
>>>>> --

Received on Monday, 6 May 2013 22:58:57 UTC