Re: ZIP archive API?

On Mon, May 6, 2013 at 6:36 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, May 6, 2013 at 8:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> > I'm not aware of any optimized inflate implementation in JS to compare
>> > against, and it's a complex algorithm, so nobody is likely to jump
>> > forward
>> > to spend a lot of time implementing and heavily optimizing it just to
>> > show
>> > how slow it is.  I've seen an implementation around somewhere, but it
>> > didn't
>> > use typed arrays so it would need a lot of reworking to have any
>> > meaning.
>>
>> Likewise, I don't see any browser vendor jumping ahead and doing both
>> the work to implement a library *and* and API to compare the two.
>
> Sorry, this didn't make sense.  What "library *and* API" are you talking
> about?  To compare what?

A library for zip compression/decompression and an API for zip
compression/decompression. So that we can compare the performance of
the two.

>> > Every browser already has native inflate, though.
>>
>> This is unfortunately not a terribly strong argument. Exposing that
>> implementation through a DOM API requires a fairly large amount of
>> work. Not to add maintaining that over the years.
>
>
> You're arguing for allowing accessing files inside ZIPs by URL, which means
> you're going to have to do the work anyway, since you'd be able to create a
> blob URL, reference a file inside it using XHR, and get a Blob as a result.
> This is a small subset of that.

No, the work to write and maintain an API for ZIP
compress/decompression is pretty orthogonal, implementation-wise, to a
protocol handler for ZIP decompression.

Look, the fact that we need use cases should not be surprising to
people on this mailing list. And I know that it's not surprising to
you. One of the heavy arguments that has been brought up for a "ZIP
archive API" has been that it provides better performance. That's a
claim that needs to be backed up by numbers in order to carry any
weight.

The argument that you're bringing up is "it's easy to implement
(because you already have an zip library)" is also a very weak
argument.

Until we get stronger arguments for an archive API, I'd be happy to
see a proposal for a protocol handler.

/ Jonas

Received on Tuesday, 7 May 2013 06:10:30 UTC