Re: File API: reading a Blob

On Wed, Jul 2, 2014 at 7:06 PM, Arun Ranganathan <arun@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 /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?

It's unclear to me why we'd want to use the event loop for this,
basically. Also, the current set of synchronous steps (which I could
opt not to use, granted, but other APIs already might, and I'd like us
to be consistent) simply return failure when something bad happens
rather than returning the bytes read so far. It seems like that is a
problem, perhaps following from not having this lower-level
description.


On Wed, Jul 2, 2014 at 8:51 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> Or are you trying to transfer from a vague conceptual model of "/blob/'s underlying data stream" to a different conceptual model of "A body is a byte stream," only to later actually reify the "byte stream" as a stream object? That seems potentially problematic, but perhaps it could be made to work...

Yes.

E.g. for <img> there would not be an observable stream here. Just some
of the effects (JPEG progression) might be observable. Fetch is the
model of the networking layer, there are no concrete JavaScript
objects there.


-- 
http://annevankesteren.nl/

Received on Thursday, 3 July 2014 08:15:26 UTC