Re: File API: reading a Blob

Welcome back - we missed you :-)


On Aug 5, 2014, at 9:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jul 17, 2014 at 2:58 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>> There are two questions:
>> 
>> 1. How should FileReaderSync behave, to solve the majority of use cases?
>> 2. What is a useful underlying abstraction for spec. authors that can be reused in present APIs like Fetch and future APIs?
> 
> I'm not sure.


I strongly think we should leave FileReaderSync and FileReader alone. Also note that FileReaderSync and XHR (sync) are not different, in that both don’t do partial data. But we should have a stream api that evolves to read, and it might be something off Blob itself.

That leaves us the next problem, and what I think is the last problem in File API:



>>> Yeah, I now think that we want something even lower-level and build
>>> the task queuing primitive on top of that. (Basically by observing the
>>> stream that is being read and queuing tasks as data comes in, similar
>>> to Fetch. The synchronous case would just wait for the stream to
>>> complete.
>> 
>> If I understand you correctly, you mean something that might be two-part (some hand waving below, but …):
>> 
>> To read a Blob object /blob/, run these steps:
>> 
>> 1. Let /s/ be a new buffer.
>> 
>> 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.
>> 
>> AND
>> 
>> To read a Blob object with tasks:
>> 
>> 1. Run the read a Blob algorithm above.
>> 2. When reading the first /bytes/ queue a task called process read.
>> 3. When pushing /bytes/ to /s/, queue a task called process read data.
>> 4. When all /bytes/ are pushed to /s/ queue a task called process read EOF.
>> 5. If an error condition is signaled queue a task called process error with a failure reason.
>> 
>> Is “chunk” implementation defined? Right now we assume 1 byte or 50ms. “Chunk” seems a bit hand-wavy and hard to enforce, but… it might be the right approach.
> 
> Would have to discuss with Domenic, but something like chunks seems to
> be much closer to how these things actually work.


Other than “chunks of bytes” which needs some normative backbone, is the basic abstract model what you had in mind? If so, that might be worth getting into File APi and calling it done, because that’s a reusable abstract model for Fetch and for FileSystem.

— A*

Received on Friday, 8 August 2014 15:57:33 UTC