Yes and yes
On Wed, Feb 6, 2013 at 12:06 PM, Filip Maj <[email protected]> wrote: > In light of recent discussion re: figuring out whether to add new > constants for various FileSystem locations (I.e. PERSISTENT vs TEMPORARY > vs APP vs SOMENEWDIRECTORYLOCATION), perhaps we should chime in on this > new thread that came into the web apps WG? > > On 2/6/13 11:58 AM, "Arun Ranganathan" <[email protected]> wrote: > >>Greetings WebApps WG! >> >>Review on the File API is encouraged: >> >>http://dev.w3.org/2006/webapi/FileAPI/ >> >>A few substantial changes that might need particular attention before we >>initiate a call for LCWD or something comparably official: >> >>1. autoRevoke behavior of Blob URIs has changed. Previous drafts made >>the autoRevoke behavior on by default (by consensus), but didn't harness >>revocation to a suitable and unambiguous "scope." Thanks to a fix to >>HTML[1] we can leverage the global script clean-up jobs list, to which we >>add revocation of Blob URIs. Blob URIs are thus either scoped to the >>next time global script clean-up jobs are processed (by default), OR when >>document unloading steps are processed if the developer opts out of the >>default but never pairs it with a call to URL.revokeObjectURL, OR when >>URL.revokeObjectURL is called. >> >>In particular, this behavior defers from shipping implementations such as >>IE10. This is possibly the biggest change: >> >>http://dev.w3.org/2006/webapi/FileAPI/#lifeTime >> >>http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking >> >>2. An utility to smooth line ending variations (Unix vs. Windows) has >>been added, but is an orphan interface currently. Nobody's fussed over >>this, and it might not be a problem at all, but I'd like to draw your >>attention to it :) While currently only relevant for DOMString arguments >>to the Blob constructor, we might work with the utility to add other >>arguments (including ArrayBufferViews, etc.). >> >>http://dev.w3.org/2006/webapi/FileAPI/#convenienceAPI >> >>3. Progress events have been clarified. >> >>4. readAsDataURL currently makes progress notifications throughout the >>read, but only returns a non-null return value at the end of the read. >> >>http://dev.w3.org/2006/webapi/FileAPI/#readAsDataURL >> >>Specification bugs still exist, and this draft doesn't address all open >>bugs [2]; further bugs and issues, if any, should be logged or discussed >>on this listserv. The remaining bugs present use cases that aren't major >>enough to warrant feature extensions. >> >>-- A* >> >>[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554 >> >>[2] >>https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Fil >>e%20API&resolution=---&list_id=4913 >
