Re: ZIP archive API?

I second that. Thanks Florian.




On 05/03/2013 02:52 PM, Florian Bösch wrote:
> 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/
>
>