RE: File API "oneTimeOnly" is too poorly defined

We agree that the spec text should be updated to more clearly define what dereference means. 
When we were trying to solve this problem, we looked for a simple and consistent way that a developer can understand what dereferencing is. 
What we came up with was the following definition: revoking should happen at the first time that any of the bits of the BLOB are accessed. 

This is a simple concept for a developer to understand, and is not complex to spec or implement. This also helps avoid having to explicitly spec 
out in the File API spec the various edge cases that different APIs exhibit – such as XHR open/send versus imgtag.src load versus css link href 
versus when a URL gets resolved or not. Instead those behaviors will continue to be documented in their respective spec.

The definition above would imply that some cases, such as a cross-site-of-origin request to a Blob URL do not revoke, but we think that is OK 
since it implies a developer error. If we use the above definition for dereferencing, then in the XHR example you provided, xhr.send would 
be responsible for revoking the URL.

Thanks,
Feras

>From: Charles Pritchard [mailto:chuck@jumis.com] 
>Sent: Thursday, March 29, 2012 1:03 AM
>To: Glenn Maynard
>Cc: Jonas Sicking; public-webapps WG
>Subject: 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.
>>
>>

Received on Monday, 9 April 2012 22:53:34 UTC