RE: File API: reading a Blob

I am a little unclear as to what you are trying to accomplish here.

>From my perspective streams are not really an abstract concept, but instead are specific JavaScript APIs that conform to a given contract. In contrast, an underlying source [1] is an abstract concept; a given (readable) stream object wraps such an abstract underlying source.

Are you trying to specify the stream object itself? Your "/s/" seems like it might be that. In which case, I think the most rigorous approach is that taken by Claes in [2]; see e.g. step 10. The terminology has changed a tiny bit since he wrote it (s/push/enqueue/g, and we try to use the word "chunk" now), but the basic idea is sound. I think in your case you are describing a pull underlying source, whereas his was a push, so most of your stuff would go in pull() instead of start(). Also I don't think failure signals are usually in the /bytes/, but instead out-of-band (e.g. return codes from syscalls).

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...

[1]: https://whatwg.github.io/streams/#rs-model
[2]: http://www.w3.org/2012/sysapps/tcp-udp-sockets/#interface-tcpsocket
________________________________________
From: annevankesteren@gmail.com <annevankesteren@gmail.com> on behalf of Anne van Kesteren <annevk@annevk.nl>
Sent: Wednesday, July 02, 2014 10:28
To: WebApps WG; Arun Ranganathan
Cc: Domenic Denicola
Subject: File API: reading a Blob

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 18:52:14 UTC