Re: Lifetime of Blob URL

On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman <adrianba@microsoft.com>wrote:

> 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.
>

Yes. Unfortunately, another way of saying that "the url lives as long as the
Blob lives" is "the url lives until the Blob is garbage collected". This
exposes a very indeterminate behavior.



>
> > 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?


http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0000.html
See point #5 basically once a load has started for a url, that
load should succeed and revoke may be called.



> Is there
> reference counting so that if I call create twice I have to call revoke
> twice?
>

I don't think this has been specified, but a simple proposal would be that
each create call would result in a unique url.





>
> Thanks,
>
> Adrian.
>