W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2013

Re: [whatwg] Assigning media resources represented as DOM objects to a media element

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 15 Feb 2013 08:46:02 -0600
Message-ID: <CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
To: robert@ocallahan.org
Cc: whatwg <whatwg@lists.whatwg.org>
On Tue, Jan 22, 2013 at 9:19 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> Currently the only way to use one of these objects as the source of a media
> element is via "element.src = URL.createObjectURL(object)". This is
> problematic because the URLs minted by createObjectURL require manual
> revocation. (Forms of auto-revocation have been proposed but a) they seem
> difficult to spec in a rational way and b) we will not be able to make
> auto-revocation the default.)


a) This isn't the case.  The tricky bit was defining precisely when
autorevocation happens; this has been resolved (the "global script clean-up
jobs list").  There's a remaining piece (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll take
some thought to do that in a clean way (so it can be applied to different
APIs concisely), there's nothing magic there.
b) Even if we can't make it the default, there are much cleaner solutions
than bloating other APIs.  For example, a separate method can default to
auto-revoke, so you can say eg. img.src = blob.createRevokingURL().  I
don't like adding APIs that are just copies of other APIs with different
defaults, but it's much less evil than adding a whole separate mechanism.
In any case, explicitly saying img.src = URL.createObjectURL(blob,
{autoRevoke: true}) isn't actually that painful.

-- 
Glenn Maynard
Received on Friday, 15 February 2013 14:46:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:19 UTC