Re: Discussion of File API at TPAC in Lyon

On Thu, Nov 11, 2010 at 1:06 PM, Arun Ranganathan
<aranganathan@mozilla.com> wrote:
>> On Thu, Nov 11, 2010 at 11:18 AM, Eric Uhrhane <ericu@google.com>
>> wrote:
>> > On Thu, Nov 11, 2010 at 10:02 AM, Jonas Sicking <jonas@sicking.cc>
>> > wrote:
>> >> 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).
>> >>
>> >> Actually, this was a brain-fart on my part. What was suggested was
>> >> that we simply allow:
>> >>
>> >> img.src = myFile;
>> >> img.src = myBlob;
>> >> img.src = myFutureStream;
>> >> img.src = "http://www.sweden.se/ABBA.jpg";
>> >>
>> >> These things could be implemented without lifetime worries.
>> >>
>> >> What we might need is a IDL construct so that a specification can
>> >> just say
>> >>
>> >> interface HTMLImageElement {
>> >>  ...
>> >>  attribute URLThingamajig src;
>> >>  ...
>> >> };
>> >>
>> >> Which would automatically define that it accepts
>> >> files/blobs/strings.
>> >> And gives us a central place to update when we want to add streams
>> >> and
>> >> other things.
>> >
>> > While this is a clean API, it doesn't work for passing URLs to
>> > plugins, and it doesn't work when folks construct a bunch of DOM via
>> > innerHTML. And if you add a way to get a string from one of these
>> > objects, you're back with the lifetime problem again.
>>
>> Oh, definitely, we still need the createObjectURL/revokeObjectURL
>> functions. Sorry, that was probably unclear.
>>
>> However we're still left without a place to put them. Maybe it's as
>> simple as putting them on the document object? That works nicely since
>> their lifetime is scoped to that of the document object.
>>
>
>
> If we're going to keep both functions around, then it's honestly not *that much* of an improvement to move them from window* to document*, is it?  In this case, since we're going to add something to HTMLImageElement, why not leave createObjectURL and revokeObject URL well alone as part of window*?

I think the concern is that functions on window can collide with
javascript functions that webpages can define. I.e. there's a risk
that there are pages out there with code like:

function createObjectURL(x, y, z) {
  doSomethingCompletelyUnrelatedToBlobs(z, x + y);
}

> So it looks like we'll add a [Supplemental] to interfaces like HTMLImageElement allowing them to take a "src" object, and we can then define *that* src object to accomodate Stream and Blob use case scenarios.  I'm amenable to first introducing that extension to HTMLImageElement in File API if everyone else is :)

I'd be fine with that, but might also be easy to ask that this is
added to the HTML5 spec.

/ Jonas

Received on Thursday, 11 November 2010 21:14:30 UTC