Re: Discussion of File API at TPAC in Lyon

On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan
<aranganathan@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/
>
>

Received on Thursday, 11 November 2010 19:13:27 UTC