W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: Discussion of File API at TPAC in Lyon

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 11 Nov 2010 10:02:04 -0800
Message-ID: <AANLkTimNuDXNTgsntxxEtQmKrOT70jU_GbzUmfB8FVB6@mail.gmail.com>
To: Arun Ranganathan <aranganathan@mozilla.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Jian Li <jianli@chromium.org>
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.

/ Jonas
Received on Thursday, 11 November 2010 18:02:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC