On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan <aranganat...@mozilla.com> wrote: > 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).
While I agree that we came up with the new top-level object [called the "dummy object" in the minutes] to hold createObjectURL and revokeObjectURL, I don't think we actually threw away the second method. It would still be useful to be able to throw away Blob URLs explicitly, so as to avoid keeping the Blobs around forever in long-lived windows. Also, I believe we decided that this should be disjoint from the URL object that abarth is speccing: " arun: is it worth make global dummy object the same thing being specced by adam barth no jonas: abarth's thing is to solve parsing urls. this isn't want we need to do with blob urls anne: not so sure jonas: there's a vague resemblance given that they both revolve around URLs sam: agrees ... especially since adam's thing doens't exist yet" Checking again, my interpretation of the minutes is the same as my memory, so I can't possibly be mistaken ;'>. > 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. Yeah, I think we made some good progress there, but no conclusions. I'll start another thread about the headers. > 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/ > >
