From: Florian Bösch <[email protected]<mailto:[email protected]>>
Date: Fri, 3 May 2013 21:05:17 +0200
To: Jonas Sicking <[email protected]<mailto:[email protected]>>
Cc: Paul Bakaus <[email protected]<mailto:[email protected]>>, Anne van
Kesteren <[email protected]<mailto:[email protected]>>, Webapps WG
<[email protected]<mailto:[email protected]>>, Charles McCathie Nevile
<[email protected]<mailto:[email protected]>>, Andrea Marchesini
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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"
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Date: Fri, 3 May 2013 14:52:36 +0200
To: Anne van Kesteren <[email protected]<mailto:[email protected]>>
Cc: Paul Bakaus <[email protected]<mailto:[email protected]>>, Charles McCathie
Nevile <[email protected]<mailto:[email protected]>>, public-webapps WG
<[email protected]<mailto:[email protected]>>, Andrea Marchesini
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> wrote:
On Thu, May 2, 2013 at 1:15 AM, Paul Bakaus
<[email protected]<mailto:[email protected]>> 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/
