- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 22 Dec 2015 16:03:34 -0500
- To: "Liam R. E. Quin" <liam@w3.org>, Daniel Weck <daniel.weck@gmail.com>, Ivan Herman <ivan@w3.org>
- Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
On 22/12/2015 15:53 , Liam R. E. Quin wrote: > On Tue, 2015-12-22 at 18:09 +0000, Daniel Weck wrote: >> A browser-native "zip" API would be useful > > Note that gzip and zip are totally different beasts. > > Not only are they different compression algorithms, but zip is an > archive format (multiple files in a single archive) and gzip is stream- > based (a single file). > > The gzip compression is the one used by Web servers for HTTP, not zip. Yup. Also, an API for zip is not "just" a matter of exposing the format. There is the issue of the API itself of course, but more annoyingly there are intrinsic problems with zip as a format. Just to pick one issue, the paths in it could be URI-like (with escapes) or IRI-like. You need to pick one (or pick an algorithm for chosing one). In order for a useful Web API to be exposed, it ought to be made interoperable. The widgets spec gets some of the way there, but it's still work. -- • Robin Berjon - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing •
Received on Tuesday, 22 December 2015 21:04:00 UTC