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

Re: Discussion of File API at TPAC in Lyon

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Thu, 11 Nov 2010 13:06:59 -0800 (PST)
To: Jonas Sicking <jonas@sicking.cc>
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Jian Li <jianli@chromium.org>, Eric Uhrhane <ericu@google.com>
Message-ID: <291687746.333987.1289509619278.JavaMail.root@cm-mail03.mozilla.org>
> 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*?

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 :)

-- A*
Received on Thursday, 11 November 2010 21:07:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT