At the recent Technical Plenary and All WG Meetings in Lyon, File API[1] was discussed, and there are some take away action items that I minuted for myself for File API, but I'm not sure they are reflected in ACTION items, etc. From my own notes:
Essentially, strong opinions were voiced against having top-level methods createObjectURL and revokeObjectURL. So the biggest change was to introduce a new top-level object (ObjectURL) which would have methods to obtain a string Blob URI. This removes the need for a revocation mechanism, since now the ObjectURL object (which would take as a constructor the Blob object) would oversee lifetime issues. This is a big change, but potentially one that allows us to work with the emerging URL API (which hopefully is going somewhere). There were additional discussions about Content-Disposition and further headers introduced to Blob URIs, but we agreed that this should go to the listserv for further discussion. The question of *further* HTTP-like behaviors on Blob URIs is still open for discussion. Notably, Content-Disposition is desired for download management, but using a header to toggle browser behavior seems a bit arbitrary, and there may be better ways to approach the issue. While I look forward to the minutes from the WebApps meeting, does anyone in attendance agree or disagree that these are the main points to take away, or wish to add something else? Note that at least two implementations are around the corner with window.createObjectURL and window.revokeObjectURL. Vendor prefixing is a viable option in the mean time. -- A* [1] http://www.w3.org/TR/FileAPI/
