W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2012

Re: [whatwg] Archive API - proposal

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 16 Aug 2012 09:39:23 -0500
Message-ID: <CABirCh-C2zdERCjVSXbfkUgArL+N3Zi-uqqdndp2PMPt5yX64A@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: whatwg@whatwg.org, Andrea Marchesini <baku@mozilla.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:44 UTC