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

Re: [FileAPI] createObjectURL isReusable proposal

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 14 Dec 2011 10:42:52 +0100
To: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Adrian Bateman" <adrianba@microsoft.com>
Cc: "Feras Moussa" <ferasm@microsoft.com>
Message-ID: <op.v6g3xqxa64w2qv@annevk-macbookpro.local>
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman  
<adrianba@microsoft.com> wrote:
> At TPAC [1,2] I described our proposal for adding an isReusable flag to
> createObjectURL. A common pattern we have seen is the need for a blob URL
> for a single use (for example, loading into an <img> element) and then
> revoking the URL. This requires a fair amount of boilerplate code to
> handle the load/error events.
> createObjectURL is modified as follows:
> static DOMString createObjectURL(Blob blob, [optional] bool isReusable);
> The value of isReusable defaults to true if it is not supplied and this
> results in the behaviour documented for File API today. However, if you
> supply false for the flag then the first dereference of the URL revokes  
> it.
> This means that you can do something like:
> imgElement.src = URL.createObjectURL(blob,false)
> and not worry about having to call URL.revokeObjectURL to release the  
> Blob.

I think we should solve this by assigning an object directly to attributes  
that take a URL.

So instead you would get

  imgElement.src = blob

which is much cleaner I think. (The content attribute would then be set to  
"about:object-url" or some such.)

Anne van Kesteren
Received on Wednesday, 14 December 2011 09:43:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC