- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 6 May 2013 11:42:46 -0700
- To: Robin Berjon <robin@w3.org>
- Cc: Florian Bösch <pyalot@gmail.com>, Webapps WG <public-webapps@w3.org>
On Mon, May 6, 2013 at 4:27 AM, Robin Berjon <robin@w3.org> wrote: > On 03/05/2013 21:05 , Florian Bösch wrote: >> >> It can be implemented by a JS library, but the three reasons to let the >> browser provide it are Convenience, speed and integration. > > Also, one of the reasons we compress things is because they're big.* > Unpacking in JS is likely to mean unpacking to memory (unless the blobs are > smarter than that), whereas the browser has access to strategies to mitigate > this, e.g. using temporary files. There's nothing here that implementations can do that JS can't. Both can read arbitrary parts of a file into memory and decompress only that data. And both would have to load data into memory in order to decompress it. The only things that implementations can do that JS can't is: * Implement new protocols. I definitely agree that we should specify a jar: or archive: protocol, but that's orthogonal to whether we need an API. * Implement Blob backends. In our prototype implementation we were able to return a Blob which represented data that hadn't been compressed yet. When the data was read it was incrementally decompressed. But a JS implementation could incrementally decompress and write the data to disk using something like FileHandle or FileWriter. So the same capabilities are there. > Another question to take into account here is whether this should only be > about zip. One of the limitations of zip archives is that they aren't > streamable. Without boiling the ocean, adding support for a streamable > format (which I don't think needs be more complex than tar) would be a big > plus. Indeed. This is IMO an argument for relying on libraries. Implementations are going to be a lot more conservative about adding new archive formats, since they have to be supported for eternity, than library authors will be. I'm still hoping to see some performance numbers from the people arguing that we should add this to the platform. Without that I see little hope of getting enough browser vendors behind this. / Jonas
Received on Monday, 6 May 2013 18:43:44 UTC