W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [File API] Blob URI creation

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 31 May 2012 18:27:55 +0200
Message-ID: <4FC79C0B.10305@alvestrand.no>
To: Rich Tibbett <richt@opera.com>
CC: public-webapps <public-webapps@w3.org>
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
>
>
>
Received on Thursday, 31 May 2012 16:28:26 GMT

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