Hi - just want to say that I support Rich fully in this comment -
createObjectURL is Just Not Right.
I came at this through another pathway - creating mocks in Javascript.
As it is, createObjectURL can't be mocked because it is a function on
Window that is assumed to look at the type of the object passed to it
before deciding what to do about it. This means that you either mock out
or override the function on Window (having to pass through the
functionality for all other types than the one you're mocking), or
you're sharply limited in what you can mock.
If createObjectURL was *defined* (for backwards compatibility) as
window.createObjectURL = function(object) {
return object.url
}
a mock that "behaved like a File" or "behaved like a MediaStream" would
be far simpler to write, with much less chance of affecting other
behaviour than that of the specific mocked-out type.
On 05/30/2012 06:09 PM, Rich Tibbett wrote:
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
