W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

RE: Lifetime of Blob URL

From: Adrian Bateman <adrianba@microsoft.com>
Date: Mon, 12 Jul 2010 15:39:10 +0000
To: David Levin <levin@google.com>
CC: "arun@mozilla.com" <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB2F2E5827@TK5EX14MBXC140.redmond.corp.microsoft.com>
On Monday, July 12, 2010 8:24 AM, David Levin wrote:
> On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman <adrianba@microsoft.com>
> wrote:
> > Making the blob url identical to the lifetime of the blob itself would
> > expose when garbage collection takes place and in general could lead to
> > easy to make mistakes in which the developer had something that work
> > mostly but not always -- your situation below is just one of them.
> >
> > Check out the Jian Li's alternate proposal (see his response to "Re:
> > [File API] Recent Updates To Specification + Co-Editor" on July 1, I
> > think) that addresses this in a way that addresses your concerns and the
> > gc issue as well.
> The problem with an explicit revoke call is that people need to know to
> call it, need to actually call it, and need to know when it is appropriate
> to call. Many of the same timing issues that cause potential problems with
> GC also make it hard for web developers to know when to call revoke.
> 
> When GC occurs is indeterminate and would vary greatly between browsers.
> Developing features which exposes the gc behavior would lead developers
> into accidentally relying on browser specific behaviors (which may even break
> for the same browser during upgrades).

The behaviour would have to be explicitly specified and not left to depend on
indeterminate browser implementations.

> As I read Jian's proposal, there is a create call (blob.url would go away),
> so there would clearly be a revoke (or destroy call).
> 
> With respect to timing issues, the behavior of revoke with respect to load is
> clearly defined in his proposal which result in very deterministic behavior.

My apologies. I think I missed this part - please can you provide a link to the
full proposal? At what point after I assign the src of an <img> element can I
call revoke? Can I do it immediately after the assignment or do I have to have
an onload and onerror handler for every element that uses it? With XHR do I have
to wait for readyState 4 or can I call revoke earlier in the process? Is there
reference counting so that if I call create twice I have to call revoke twice?

Thanks,

Adrian.
Received on Monday, 12 July 2010 15:40:48 GMT

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