Hi,
Right now we call window.URL.createObjectURL to obtain a Blob URI.
As a developer I'd like Blob URI creation functions to hang off the Blob
interface directly making things a bit simpler and more intuitive.
It seems like we could be far less verbose in Blob URI creation by
making a Blob.url method that would return a new, unique, one-time only
Blob URI at all times. That means we won't have long-lived Blob URIs
living in a document and developers won't need to call revokeObjectURL
on Blob URIs obtained in this way.
The first time any resulting Blob URI is dereferenced then user agents
would automatically revoke the associated Blob URI, preventing reuse
elsewhere. If the web app needed a new Blob URI to use elsewhere they
would call Blob.url again to obtain a new, unique, one-time only Blob URI.
It's not obvious that we should let Blob URIs hang around indefinitely
or make developers responsible for calling revokeObjectURL manually.
Since the creation of a Blob URI seems to have relatively little
overhead, it seems reasonable that we could create a new Blob URI each
time .url is called.
I wrote a quick Blob.url shim that should help to demonstrate this proposal:
http://jsfiddle.net/MV233/
The same addition would apply for MediaStream (i.e. MediaStream.url)
though the spec says createObjectURL only takes a Blob object at the
moment (which seems wrong but that is what I'm working to).
This API method could alternatively be called .getURL or .createURL. The
method does return dynamic content and it does seem to act more like a
method than an attribute so that would make sense IMO.
At best this would be a replacement for window.URL.createObjectURL. At
worst, it's a convenient shortcut for developers to creating and using
no-nonsense Blob URIs.
--
Rich Tibbett
Opera Software ASA
