Re: File API "oneTimeOnly" is too poorly defined

Any feedback on what exists in modern implementations? MS seems to have the most hard-line stance when talking about this API.

When it comes to it, we ought to look at what happened in the latest harvest. IE10, O12, C19, and so forth.



On Mar 28, 2012, at 6:12 PM, Glenn Maynard <glenn@zewt.org> wrote:

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