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

Re: [FileAPI] createObjectURL isReusable proposal

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 13 Dec 2011 18:55:16 -0800
Message-Id: <C536E462-FE51-4FB9-8B0D-EBCCE9DB0081@jumis.com>
Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Feras Moussa <ferasm@microsoft.com>
To: Adrian Bateman <adrianba@microsoft.com>
I've seen the same pattern, though mysteriously, running a revoke in the same loop still allows the image to be loaded. I may have made a mistake in reading those source files or it may be a special quirk in the order of event loading.

However this is approached, I think it should have firm roots in the operation of the event loop.

On Dec 13, 2011, at 4:52 PM, 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.
> We have implemented this in experimental form in IE10 preview builds and
> it works well. There seemed to be a fair amount of support at TPAC and we're
> hoping this will be adopted in the File API spec.
> Thanks,
> Adrian.
> [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02
> [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
Received on Wednesday, 14 December 2011 02:55:51 UTC

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