Enable compression of a blob to .zip file
Hi all I've tried to search the Webapps and WHATWG mailing lists for previous discussions about this request, but I haven't been able to find anything. My request can be explained easily: when uploading files to the server, many times the upload time can be improved greatly if the file is compressed instead of sent as-is; in my case I've adjusted some systems that requires the user to upload a data file so it can accept both the original file (mdb, csv, .xls, ), or a compressed version in .zip When the user remembers to compress the zip everything goes fine, but many times people might not be aware of that option, and so I think that it would be useful to have an option (whatever objects or proposal about methods are just quick ideas to explain the concept) on a Blob object to compress it to a .zip and so get a new Blob So the flow would be 1. User picks his data file with input type=file 2. JS starts a XHR upload to show a progress bar 3. JS checks that the file is uncompressed, so it creates a zipped blob: var file = input.files[0]; var extension = file.name.match( /\.([^\.]+)\s*$/ )[ 1 ]; if (extension.toLowerCase() != 'zip') file = file.toZip( 'compressed.zip' ); formData.append( file ); etc... 4. And the rest of the upload goes as usual. 5. The server gets the file and uncompresses it (the server doesn't really care if the file was compressed in js or because the user did it, but the js code can add a flag in the xhr upload to signal that it was autocompressed. Instead of a method on a Blob, it could be a separate object similar to Mozilla nsIZipWriter (https://developer.mozilla.org/en/nsIZipWriter), but with some simplifications to avoid extra verbose code. var zipWriter = new zipWriter( 'compressed.zip' ); // This way it could be possible to add several files into the zip zipWriter.addEntryFile( file); formData.append( zipWriter ); etc... Of course, in the files should be always added at the root of the zip without any info about the original path. The compression can (and probably should) be done asynchronously. Would it be possible to add this new feature to some spec? Thanks.
Re: QSA, the problem with :scope, and naming
On Sat, Oct 29, 2011 at 8:28 PM, Cameron McCormack c...@mcc.id.au wrote: On 20/10/11 3:50 AM, Alex Russell wrote: I strongly agree that it should be an Array *type*, but I think just returning a plain Array is the wrong resolution to our NodeList problem. WebIDL should specify that DOM List types *are* Array types. It's insane that we even have a NodeList type which isn't a real array at all. Adding a parallel system when we could just fix the one we have (and preserve the value of a separate prototype for extension) is wonky to me. That said, I'd *also* support the ability to have some sort of decorator mechanism before return on .find() or a way to re-route the prototype of the returned Array. +heycam to debate this point. Late replying here again, apologies, but I agree with others who say that an actual Array object should be returned from this new API given that it is not meant to be live. What benefit is there from returning a NodeList? If it's a NodeList (or something else that *subclasses* Array) we can do fun things like add .find to it, which returns the sorted union of calling .find on all the elements within it. Returning a plain Array doesn't let us do that. ~TJ
[Bug 14037] Should XMLDocument be standardized?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14037 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Status Whiteboard|(blocked on WebIDL change) | --- Comment #49 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-30 16:51:50 UTC --- Thanks! This should now be completely fixed as discussed in comment 29. Obviously don't hesitate to reopen if I made a mistake or if it turns out we need other changes. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Enable compression of a blob to .zip file
On 10/30/11 3:03 AM, Alfonso Martínez de Lizarrondo wrote: Instead of a method on a Blob, it could be a separate object similar to Mozilla nsIZipWriter (https://developer.mozilla.org/en/nsIZipWriter), but with some simplifications to avoid extra verbose code. var zipWriter = new zipWriter( 'compressed.zip' ); // This way it could be possible to add several files into the zip zipWriter.addEntryFile( file); formData.append( zipWriter ); etc... Of course, in the files should be always added at the root of the zip without any info about the original path. The compression can (and probably should) be done asynchronously. Would it be possible to add this new feature to some spec? I've repeatedly come across the need to have inflate support. There are a handful of libraries on the net implementing inflate / deflate. Licensing on them is spotty. One reason I've needed inflate is for svgz support. Browser vendors have consistently left bugs and/or ignored the spec for handling svgz files. SVG is really intended to be deflated. If we had basic inflate/deflate, it'd be trivial to support .zip, .docx and various other zip derivatives. As authors, we could also decide when to compress Blobs prior to storage. I give a big +1 to inflate/deflate. I'd also like support for base64 encoding and decoding of binary strings. Currently, base64 encoding is for DOMString and non-utf8 characters will lead to the browser throwing an error. There are work-arounds, such as using FileReader and Blob, they are indirect, practically obfuscated. I've been using a BlobString method to handle most of this work in my projects. It'd be great to have a spec to follow, so I can just use them as polyfill. These items don't require much for browser vendors. They already have support for inflate/deflate and base64 encoding. The issue, the work, is all about writing up a spec. -Charles
Re: QSA, the problem with :scope, and naming
On 30/10/11 2:28 PM, Cameron McCormack wrote: On 20/10/11 3:50 AM, Alex Russell wrote: I strongly agree that it should be an Array *type*, but I think just returning a plain Array is the wrong resolution to our NodeList problem. WebIDL should specify that DOM List types *are* Array types. It's insane that we even have a NodeList type which isn't a real array at all. Adding a parallel system when we could just fix the one we have (and preserve the value of a separate prototype for extension) is wonky to me. That said, I'd *also* support the ability to have some sort of decorator mechanism before return on .find() or a way to re-route the prototype of the returned Array. +heycam to debate this point. Late replying here again, apologies, but I agree with others who say that an actual Array object should be returned from this new API given that it is not meant to be live. What benefit is there from returning a NodeList? I think it's already been said, but if StaticNodeList (or whatever) inherits from Array then it receives array methods plus it can still have .item() for people who are assuming it is like NodeList. Sean
Re: QSA, the problem with :scope, and naming
On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack c...@mcc.id.au wrote: On 20/10/11 3:50 AM, Alex Russell wrote: I strongly agree that it should be an Array *type*, but I think just returning a plain Array is the wrong resolution to our NodeList problem. WebIDL should specify that DOM List types *are* Array types. It's insane that we even have a NodeList type which isn't a real array at all. Adding a parallel system when we could just fix the one we have (and preserve the value of a separate prototype for extension) is wonky to me. That said, I'd *also* support the ability to have some sort of decorator mechanism before return on .find() or a way to re-route the prototype of the returned Array. +heycam to debate this point. Late replying here again, apologies, but I agree with others who say that an actual Array object should be returned from this new API given that it is not meant to be live. What benefit is there from returning a NodeList? As much as I hate saying this: introducing a third return type would be counter-productive, as you'd now have live NodeList, static NodeList and subclassed Array. Congratulations, the cluster-f*ck continues in true form.
Re: Enable compression of a blob to .zip file
On 30/10/11 10:54 AM, Charles Pritchard wrote: One reason I've needed inflate is for svgz support. Browser vendors have consistently left bugs and/or ignored the spec for handling svgz files. SVG is really intended to be deflated. All major browsers have support for gzipped SVG documents through correct Content-Encoding headers, as far as I'm aware. gzipped SVG documents served as image/svg+xml without Content-Encoding:gzip should be rejected, according to the spec.
Re: Enable compression of a blob to .zip file
On 10/30/11 4:11 PM, Cameron McCormack wrote: On 30/10/11 10:54 AM, Charles Pritchard wrote: One reason I've needed inflate is for svgz support. Browser vendors have consistently left bugs and/or ignored the spec for handling svgz files. SVG is really intended to be deflated. All major browsers have support for gzipped SVG documents through correct Content-Encoding headers, as far as I'm aware. gzipped SVG documents served as image/svg+xml without Content-Encoding:gzip should be rejected, according to the spec. I've had issues with data uris and locally stored files in WebKit. -Charles
Re: Enable compression of a blob to .zip file
* Cameron McCormack wrote: On 30/10/11 10:54 AM, Charles Pritchard wrote: One reason I've needed inflate is for svgz support. Browser vendors have consistently left bugs and/or ignored the spec for handling svgz files. SVG is really intended to be deflated. All major browsers have support for gzipped SVG documents through correct Content-Encoding headers, as far as I'm aware. gzipped SVG documents served as image/svg+xml without Content-Encoding:gzip should be rejected, according to the spec. Then he probably means file system files and not HTTP files, and support there has indeed been spotty in the past. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Enable compression of a blob to .zip file
On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote: Then he probably means file system files and not HTTP files, and support there has indeed been spotty in the past. Ah, yes. Regarding data: URIs, someone should really just amend the RFC to allow specifying a content encoding.
