On Mon, May 6, 2013 at 4:27 AM, Robin Berjon <ro...@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
* 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

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

Reply via email to