W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: File API: reading a Blob

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 2 Jul 2014 13:06:29 -0400
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
Message-Id: <7995F622-77FF-408D-9AC1-D518D3D5981F@mozilla.com>
To: Anne van Kesteren <annevk@annevk.nl>
On Jul 2, 2014, at 10:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> So what I need is something like this:
> 
>  To read a Blob object /blob/, run these steps:
> 
>  1. Let /s/ be a new body. [FETCH]
> 
>  2. Return /s/, but continue running these steps asynchronously.
> 
>  3. While /blob/'s underlying data stream is not closed, run these
>     substeps:
> 
>     1. Let /bytes/ be the result of reading a chunk from /blob/'s
>        underlying data.
> 
>     2. If /bytes/ is not failure, push /bytes/ to /s/ and set
>        /s/'s transmitted to /bytes/'s length.
> 
>     3. Otherwise, signal some kind of error to /s/ and terminate
>        these steps.




Are you sure this simply cannot be done with the existing read operation, which uses annotated tasks for asynchronous use? The existing read operation serves FileReader and FileReaderSync (and maybe other APIs in FileSystem) and hopefully Fetch too.

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 /blob/.
3. To process read…
4. To process read data, transfer each byte read to /s/ and set /s/’s transmitted to the number of bytes read.

// Chunked byte transfer is possible within the 50ms delta for process read data. We could specify that here better.//

5. To process read EOF ...
6. Otherwise, to process read error with a failure reason on /s/ ….

Why is something like that unworkable and why do we need another variant of the read operation exactly?

— A*



Received on Wednesday, 2 July 2014 17:07:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC