Re: File API "oneTimeOnly" is too poorly defined

On Wed, Mar 28, 2012 at 7:49 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> > This would still require work in each URL-consuming spec, to define
> taking a
> > reference to the underlying blob's data when it receives an object URL.
>  I
> > think this is inherent to the feature.
>
> This is an interesting idea for sure. It doesn't solve any of the
> issues I brought up, so we still need to define when dereferencing
> happens. But it does solve the problem of the URL leaking if it never
> gets dereferenced, which is nice.
>

Right, that's what I meant above.  The "dereferencing" step needs to be
defined no matter what you do.  This just makes it easier to define
(eliminating task ordering problems as a source of problems).

Also, I still think that all APIs should consistently do that as soon as it
first sees the URL.  For example, XHR should do it in open(), not in
send().  That's makes it easy for developers to understand when the
dereferencing actually happens (in the general case, for all APIs).

One other thing: "dereferencing" should take a reference to the underlying
data of the Blob, not the Blob itself, so it's unaffected by neutering
(transfers and Blob.close).  That avoids a whole category of problems.

-- 
Glenn Maynard