[Bug 25081] Make read operation really async

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081

--- Comment #25 from Jonas Sicking <jonas@sicking.cc> ---
When doing img.src = bloburl there are indeed some things that should happen
synchronously and some that should happen asynchronously. I'll avoid using the
terms "fetch" and "parse" since those are editorial constructs rather than
behavioral constructs.

When img.src = bloburl is called we should synchronously
* Find which Blob object, if any, is backing the url. If the url was revoked
  this step should fail.
* Check the closed-flag of the blob.
* Grab a reference to the underlying data so that if the blob is closed or the
  url is revoked, this no longer affects what happens. (The simplest way to do
  this would be to clone the blob, but there are certainly other ways)

And we should asynchronously
* Read the data and return it.


I don't particularly care which of the above steps live in or are triggered by
the "fetch" spec and which live in a "parse" spec.

I had assumed that we wanted img.src = X to trigger the fetch spec
synchronously, and then the fetch spec would take care of triggering all of the
above steps, both the synchronous and the asynchronous ones.

Anne, if you think that the File spec should have separate algorithms for the
synchronous and asynchronous parts, what exactly should be in the asynchronous
algorithm? Simply saying "read the data from the blob and return it" makes for
an awfully short algorithm.

I also sort of like the idea of the file spec ensuring that everyone reading
from the blob triggers only a single algorithm which ensures that all of the
above steps are performed. I.e. I wouldn't want someone to write a spec which
only triggers the "read data and return it" step.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 23 April 2014 18:24:21 UTC