Re: ZIP archive API?

On Mon, May 6, 2013 at 7:42 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

Is ZIP a protocol or simply a media type?

Either way, browsers will need to implement operations on the archive
format to understand its use in URL attributes.

The question then becomes: if browsers have an implementation of the
format for reference purposes, why do web apps need to ship their own
implementations of the format for archive purposes?

If web apps want to use some other archive/compression format, of
course they will have to distribute an implementation.

Thanks,

David

> * 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 19:17:27 UTC