Re: File API "oneTimeOnly" is too poorly defined

On Mon, Apr 9, 2012 at 5:52 PM, Feras Moussa <ferasm@microsoft.com> wrote:

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

No, this is hard to understand, because with many APIs it's not at all
obvious when the actual access happens.  It's also error-prone, as was
explained before.

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

Neither the current proposal (release at stable state) nor the previous
(release at first entry point) would require File API to specify cases for
other APIs.

Your proposal is essentially impossible to spec in an interoperable way,
because the point you propose that URLs should be released--at fetch
time--often happens in a queued task, and different APIs (and sometimes
even the same API, eg. XHR2) perform fetches in different event queues.
Some fetches happen asynchronously (eg. HTMLImageElement's "update the
image data"), in which case the ordering is even weaker.

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.


Everything that can result in a blob not being revoked is a developer
error.  The entire point of this API is to eliminate these error-prone
cases.

If we use the above definition for dereferencing, then in the XHR example
> you provided, xhr.send would
> be responsible for revoking the URL.
>

The current proposal, which there seems to be interest in, is to have the
object URL be revoked at the next stable state.  This guarantees that the
URL is always revoked.  It gives consistent behavior regardless of which
combinations of APIs are used with it.  APIs that begin fetches
synchronously would not need any modification at all, and APIs that begin
fetches asynchronously would essentially need to take a reference
synchronously (which should be fairly simple, and would be required for any
interoperable form of this API).

This model is simpler, easier to understand, easier to use, and easier to
spec; and makes it impossible for programming errors to cause leaked Blobs
(which is the very purpose of this API).

-- 
Glenn Maynard