Re: ZIP archive API?

From: Florian Bösch <pyalot@gmail.com<mailto:pyalot@gmail.com>>
Date: Fri, 3 May 2013 21:05:17 +0200
To: Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>>
Cc: Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>>, Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>>, Webapps WG <public-webapps@w3.org<mailto:public-webapps@w3.org>>, Charles McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>, Andrea Marchesini <amarchesini@mozilla.com<mailto:amarchesini@mozilla.com>>
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 good 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 deal on underpowered devices such as mobiles.

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 be done in JS.

I was going to say exactly  that. I want to be able to have a virtual URL 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 in JS.

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.




On Fri, May 3, 2013 at 8:04 PM, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> 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" <pbakaus@zynga.com<mailto:pbakaus@zynga.com>> 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 both workers and normal context.

Thanks,
Paul

From: Florian Bösch <pyalot@gmail.com<mailto:pyalot@gmail.com>>
Date: Fri, 3 May 2013 14:52:36 +0200
To: Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>>
Cc: Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>>, Charles McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>, public-webapps WG <public-webapps@w3.org<mailto:public-webapps@w3.org>>, Andrea Marchesini <amarchesini@mozilla.com<mailto:amarchesini@mozilla.com>>
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 Arraybuffer
- Serialize archive to Dataurl, Blob, URL object, File or Arraybuffer

To avoid the whole worker/proxy thing and to allow authors to selectively choose how they want to handle the data, I'd like to see synchronous and 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: http://docs.python.org/3/library/zipfile.html
- Pythons tarfile API is less clutered and easier to use: http://docs.python.org/3/library/tarfile.html
- 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 asynchronous operation needs to rely on a worker, which is bothersome to setup: http://stuk.github.io/jszip/

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 <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
On Thu, May 2, 2013 at 1:15 AM, Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>> wrote:
> Still waiting for it as well. I think it'd be very useful to transfer 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.


--
http://annevankesteren.nl/