On Wed, Jul 2, 2014 at 7:06 PM, Arun Ranganathan a...@mozilla.com wrote:
For instance, I thought the idea was that within Fetch to read /blob/ we’d
do something like:
1. Let /s/ be a new body. Return /s/ and perform the rest of the steps
async.
2. Perform a read operation [File API] on
Do you mean browser developers or editor developers? Wouldn't this task
force group be a good place? I've notified the Substance.io team about it.
Some others that might be interested, that I haven't seen here yet:
TinyMCE, Aloha, Wikimedia Wysywig editor, the WYSYWIG editor project of
PLOS,
On Jul 3, 2014, at 4:14 AM, Anne van Kesteren ann...@annevk.nl wrote:
It's unclear to me why we'd want to use the event loop for this,
basically.
The FileReader object uses the event loop; your initial request for Fetch was
to have a reusable “abstract” read operation which used tasks.
On Thu, Jul 3, 2014 at 3:58 PM, Arun Ranganathan a...@mozilla.com wrote:
You’ve since changed your mind, which is totally fine
I wish I could foresee all problems before starting to write things
out, that'd be great! :-)
but overhauling the current read operation for a change
of mind/model
On Jul 3, 2014, at 10:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
So most of Fetch is asynchronous. If it's invoked with the synchronous
flag set it's just that it waits for the entire response before
returning. That's why I'd like to use the asynchronous path of reading
a blob. But I'd
On Thu, Jul 3, 2014 at 4:29 PM, Arun Ranganathan a...@mozilla.com wrote:
OK, this is fixable. I’ll ensure that the read operation’s synchronous
component does return the results thus far, but that FIleReaderSync itself
ignores them in case of a midstream error, unless we collectively agree that
Hi folks,
Couple of issues I've bumped into recently while looking at Service Workers
more closely.
1. e.respondWith + e.waitUntil.
I feel like those are strong code smells we haven't found the right design
for yet.
I have a suggestion for waitUntil[1]. None yet for respondWith, but plan to
