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

Re: Lifetime of Blob URL

From: David Levin <levin@google.com>
Date: Mon, 12 Jul 2010 08:23:39 -0700
Message-ID: <AANLkTil_blAgY8L7Ia5lS4D9XBstHVux2_JaeLfCQ20a@mail.gmail.com>
To: Adrian Bateman <adrianba@microsoft.com>
Cc: "arun@mozilla.com" <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
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).

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

Received on Monday, 12 July 2010 15:24:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC