From: Florian Bösch <pya...@gmail.com<mailto:pya...@gmail.com>>
Date: Fri, 3 May 2013 21:05:17 +0200
To: Jonas Sicking <jo...@sicking.cc<mailto:jo...@sicking.cc>>
Cc: Paul Bakaus <pbak...@zynga.com<mailto:pbak...@zynga.com>>, Anne van
Kesteren <ann...@annevk.nl<mailto:ann...@annevk.nl>>, Webapps WG
<public-webapps@w3.org<mailto:public-webapps@w3.org>>, Charles McCathie Nevile
<cha...@yandex-team.ru<mailto:cha...@yandex-team.ru>>, Andrea Marchesini
<amarches...@mozilla.com<mailto:amarches...@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
<jo...@sicking.cc<mailto:jo...@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"
<pbak...@zynga.com<mailto:pbak...@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 <pya...@gmail.com<mailto:pya...@gmail.com>>
Date: Fri, 3 May 2013 14:52:36 +0200
To: Anne van Kesteren <ann...@annevk.nl<mailto:ann...@annevk.nl>>
Cc: Paul Bakaus <pbak...@zynga.com<mailto:pbak...@zynga.com>>, Charles McCathie
Nevile <cha...@yandex-team.ru<mailto:cha...@yandex-team.ru>>, public-webapps WG
<public-webapps@w3.org<mailto:public-webapps@w3.org>>, Andrea Marchesini
<amarches...@mozilla.com<mailto:amarches...@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
<ann...@annevk.nl<mailto:ann...@annevk.nl>> wrote:
On Thu, May 2, 2013 at 1:15 AM, Paul Bakaus
<pbak...@zynga.com<mailto:pbak...@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/
