Re: Discussion of File API at TPAC in Lyon

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.

Another possibility is putting them on the URL interface object. I.e.
not using URL objects themselves, but rather something like this:

x = URL.createObjectURL(myblock);
typeof x == "string";
URL.revokeObjectURL(x);

But I think I prefer the document solution.

/ Jonas

/ Jonas

Received on Thursday, 11 November 2010 19:47:33 UTC