RE: Lifetime of Blob URL

On Sunday, July 11, 2010 10:40 PM, David Levin wrote:
> On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman <adrianba@microsoft.com>
> wrote:
> Hi Arun, I think the updated URL section reflects a good compromise. We
> might want to call out explicitly that "opaque string" should not include
> recognisable metadata to avoid scripts from trying to parse the URL. User
> Agents that wish to include data such as origin should do so by encoding
> it in an opaque manner.
> 
> Specifying the format of contents of the url is simply an
> overspecification. Saying "User Agents that wish to include data such as
> origin should do so by encoding it in an opaque manner." is ambiguious.
> As soon as anyone publishes the format (which would be trivial to do
> given chromium's open source), the format would no longer be opaque.

Of course and I wasn't writing spec text merely raising the idea. Feel free
as always to propose some text. I think there's a clear difference between
going to find the chromium source and figuring out how to decode the origin
and seeing origin=blah in the string.

> I have one other concern about the lifetime of the blob URL [1]. The spec
> currently says that blob: URLs should have the lifetime of the Document.
> I think this is too long. An AJAX style web application may never
> navigate
> the document and this means that every blob for which a URL is created
> must be kept around in some form for the lifetime of the application.
> 
> In our discussions on this topic at Microsoft we've assumed that the
> lifetime for a blob URL will be the same as the lifetime of the blob
> itself.
> 
> 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.

> This does create something of a race condition. If I have a blob
> representing an image where I set the src of an <img> element and then
> let the blob go out of scope might it be collected before the <img> loads
> the resource? We think we'll have to include some mechanism to ensure
> that
> the blob and URL doesn't get collected before pending network requests
> have been made.
> 
> This does impose an additional burden on the web developer: if they later
> want to copy the source URL from one <img> to another then this will only
> work if they also kept the blob in scope somewhere.
> 
> What do you think?
> 
> Cheers,
> 
> Adrian.
> 
> [1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime
>

Received on Monday, 12 July 2010 12:49:09 UTC