Re: [whatwg] Archive API - proposal

On Thu, Aug 16, 2012 at 1:22 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> First of all, we're be talking about 5 vs. 6 objects per file entry:
> two ArrayBuffers, two ArrayBufferViews, one File and potentially one
> JS-object. Actually, in Gecko it's more like 8 vs. 9 objects once you
> start counting the C++ objects and their JS-wrappers.
>

That's not what I meant.  It looked like you meant passing two arrays to
onsuccess, one with metadata and one with Files, so the user would have to
reassociate them.  Rereading I see that's not what you meant.

That said, these can be methods, so the ArrayBuffers aren't allocated
unless the user wants them, which I expect would be rare:

interface ZipFile : File {
    ArrayBuffer getErrorVerificationCode();
    readonly attribute DOMString errorVerificationMethod; // always "CRC32"
for now
    ArrayBuffer getRawFilename();
};

(If all we care about is CRC32, then "readonly attribute unsigned long
expectedCRC32" instead and drop errorVerificationMethod.  I'm assuming
non-CRC32 is what you had in mind by making CRC32 an ArrayBuffer instead of
just an unsigned long.)

I'm also not a fan of sticking the crc32 on the File object itself
> since we don't actually know that that's the correct crc32 value.
>

It's the "expected CRC32", not the "CRC32", and should have an attribute
name to that effect.  It definitely doesn't belong on File itself, since
it's pretty tightly specific to archive error checking; it should use a
subclass.

-- 
Glenn Maynard

Received on Thursday, 16 August 2012 14:40:00 UTC