Re: [w3c/FileAPI] Add simpler reading methods to Blob interface. (#117)

mkruisselbrink commented on this pull request.



> @@ -551,6 +559,59 @@ It must act as follows:
   </pre>
 </div>
 
+<h4 id="stream-method-algo">
+The stream method</h4>

I was mostly trying to be consistent with the rest of the spec, but yeah agree that this should be done differently. I've cleaned up the rest of the spec and rebased this on top of that.

> @@ -551,6 +559,59 @@ It must act as follows:
   </pre>
 </div>
 
+<h4 id="stream-method-algo">
+The stream method</h4>
+
+The <dfn method for=Blob>stream()</dfn> method returns the contents
+of the blob as a {{ReadableStream}}.

Good point. This sentence really doesn't add much, and if we want any kind of non-normative bits those should be domintro notes. Removed it here and for the other methods.

> @@ -551,6 +559,59 @@ It must act as follows:
   </pre>
 </div>
 
+<h4 id="stream-method-algo">
+The stream method</h4>
+
+The <dfn method for=Blob>stream()</dfn> method returns the contents
+of the blob as a {{ReadableStream}}.
+
+It must return the result of [=getting a stream for a Blob=] for the [=context object=].
+
+To <dfn lt="get a stream for a Blob|getting a stream for a Blob">get a stream for a {{Blob}}</dfn>
+|blob|, run the following steps:
+
+1. Let |stream| be the result of [=construct a ReadableStream object|constructing=] a
+   {{ReadableStream}} object.
+1. Return |stream| and run the following steps [=in parallel=]:

Done

> +It must return the result of [=getting a stream for a Blob=] for the [=context object=].
+
+To <dfn lt="get a stream for a Blob|getting a stream for a Blob">get a stream for a {{Blob}}</dfn>
+|blob|, run the following steps:
+
+1. Let |stream| be the result of [=construct a ReadableStream object|constructing=] a
+   {{ReadableStream}} object.
+1. Return |stream| and run the following steps [=in parallel=]:
+  1. While not all bytes of |blob| have been read:
+    1. Let |bytes| be the byte sequence that results from reading a [=chunk=] from |blob|.
+    1. If a [=file read error=] occured while reading |bytes|, [$ReadableStream/error$]
+       |stream| with a [=failure reason=] and abort these steps.
+    1. [=ReadableStream/Enqueue=] |bytes| into |stream|.
+
+    Issue: We need to specify more concretely what reading from a Blob actually does, and what
+    possible errors can happen.

Not sure if size of chunks is ever going to really matter, as that shouldn't really be observable anyway... These new methods only return the whole stream in one go anyway, and while the existing FileReader methods do give you progress events those are more time-limited (with the same ~50ms as used by XHR) rather than directly tied to chunks that are pushed in the stream. And I expect this always to be somewhat hand-wavy, but at least I hope to have one place that describes how to get a ReadableStream out of a blob, and then the rest of the spec can just use that stream and not have any hand-waving or ambiguities... This "algorithm" at least doesn't seem worse than the current defintion of read operations.

> +    1. If a [=file read error=] occured while reading |bytes|, [$ReadableStream/error$]
+       |stream| with a [=failure reason=] and abort these steps.
+    1. [=ReadableStream/Enqueue=] |bytes| into |stream|.
+
+    Issue: We need to specify more concretely what reading from a Blob actually does, and what
+    possible errors can happen.
+
+<h4 id="text-method-algo">
+The text method</h4>
+
+The <dfn method for=Blob>text()</dfn> method returns the contents
+of the blob as a {{USVString}}.
+
+It must act as follows:
+
+1. Let |stream| be the the result of [=getting a stream for a Blob=] for the [=context object=].

Sure, I don't particularly mind doing things in either order. This seemed like a smaller change to start with, but the opposite is of course true as well. I'm working on the more general FileReader rewrite, and should have that uploaded soon too.

This also brings up the question if `blob.text()` should do what is described here, matching `new Response(blob).text()` (and always using UTF-8), or if it should do what `readAsText` does currently, and use the encoding that might be specified in the blob's mime type (or even have an optional encoding parameter to pass to the text method to override that default). Not sure which one is more important to be consistent with...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/pull/117#discussion_r263951438