W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Enable compression of a blob to .zip file

From: Paul Bakaus <pbakaus@zynga.com>
Date: Wed, 30 Nov 2011 01:47:56 -0800
To: Charles Pritchard <chuck@jumis.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <CAFBBA2B.12480%pbakaus@zynga.com>
Fyi - it's been a long time request from Zynga to have a web packaging
format to serve and store assets in large chunks. A relevant ticket with a
discussion can be found here:

I'm all for it, of course.

Am 31.10.11 12:20 schrieb "Charles Pritchard" unter <chuck@jumis.com>:

>On 10/31/11 11:34 AM, Boris Zbarsky wrote:
>> On 10/31/11 1:42 PM, Charles Pritchard wrote:
>>> I'm almost certain that somewhere, it is specified that the browser
>>> should sniff the first few bytes of the file to see
>>> if it is compressed.
>> I don't believe it is.  In fact, doing that would contradict the specs
>> as they stand, to my knowledge.
>> I could be wrong, of course, but in that case citation needed...
>> -Boris
>Well I've failed to find a citation. I will post one if I find it.
>In the meantime: Blob and Data uris can and should have sniffing for
>It's trivial, and it makes a whole lot more sense than extending both
>the Blob and data uri specs to include transfer encoding semantics.
>file: and filesystem: and widget urls are items that -might- be
>supported on an OS level, and thus out of scope here.
>Back to deflate use cases: PDF.js I'm sure implements deflate (for PDF
>FlateEncode), I've recently done some docx work which required deflate.
>Many servers do not host .svgz files well, and I use XHR with deflate to
>deal with that (though I would have just used blob urls if they worked).
>localStorage, indexedDB and WebSQL all require DOMString, as do most
>WebSocket implementations -- in practical use, this means base64
>encoding data. It's another area where deflate could squeeze a few more
>bytes out of existing constraints. Especially with localStorage.
>As we continue to support more-and-more document formats, deflate
>support on the client side becomes more important. Apple and MS, two
>very large vendors, have pushed ahead with using deflate in various file
>formats they use. Adobe has been doing it for some time.
>Though HTTP works quite well for negotiated compression there are more
>and more cases that are not http bound. I would very much like to see
>deflate and inflate exposed to the scripting environment. From there I
>can easily interact with several file formats. Zip included.
Received on Wednesday, 30 November 2011 09:48:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC