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

File API: reading a Blob

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 2 Jul 2014 16:28:10 +0200
Message-ID: <CADnb78g=xmSC0n3D2Sqx5N-G94f_cgVutjYAsO7djnQFYTMUTQ@mail.gmail.com>
To: WebApps WG <public-webapps@w3.org>, Arun Ranganathan <arun@mozilla.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>
I tried to work out Fetch/Blob integration today.

What I actually want is that reading a Blob is basically pushing the
IO bytes that are read in chunks into a stream. Specifically, a body:
http://fetch.spec.whatwg.org/#concept-body

That should also make it clearer what happens if the underlying data
is borked somehow (file is moved, disk corrupted). Presumably that
signals some kind of error to the stream, but would not cause complete
failure. Something similar to a network connection going down while in
transmission.

I also don't really need the synchronous flag for this purpose. I just
need an algorithm (invoked async) that pushes data from disk on this
stream. Making the fetch appear synchronous is handled elsewhere.

The only problem with doing this is that we don't really have a good
way to talk about streams in the abstract yet. Standards such as
Encoding define some terminology, but it's not really a complete model
yet, there's certainly no error handling.

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.

What do you think?


-- 
http://annevankesteren.nl/
Received on Wednesday, 2 July 2014 14:28:38 UTC

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