--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/preview.html Tue Nov 05 21:29:10 2013 +0900
@@ -0,0 +1,1157 @@
+<!DOCTYPE html>
+
+<html>
+
+<head>
+ <title>Streams API</title>
+ <meta content="text/html;charset=utf-8" http-equiv="Content-Type">
+
+<!-- <script class=remove src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js"></script> -->
+
+ <script class="remove" src="https://www.w3.org/Tools/respec/respec-w3c-common"></script>
+ <!--<script class="remove" src="respec-w3c-common.js"></script>-->
+
+ <script class="remove">
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "streams-api",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "yyyy-mm-dd",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "yyyy-mm-dd",
+ // previousMaturity: "WD",
+
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ //extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css",
+ // "http://www.w3.org/StyleSheets/TR/W3C-ED.css",
+ // ],
+
+ // editors, add as many as you like
+ // only "name" is required
+
+ localBiblio: {
+ "EncodingDetermination": {
+ title: "Encoding",
+ href: "http://encoding.spec.whatwg.org/",
+ authors: ["Anne van Kesteren", "Joshua Bell"],
+ publisher: "WHATWG"
+ }
+ },
+
+ editors: [
+ { name: "Feras Moussa", url: "mailto:feras.moussa@hotmail.com",
+ company: "Invited Expert", },
+ { name: "Takeshi Yoshino", url: "mailto:tyoshino@google.com",
+ company: "Google, Inc.", },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "W3C Web Applications (WebApps)",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2008/webapps/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-webapps",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "",
+ };
+ </script>
+
+ <!-- Styles to mimic File API spec -->
+ <!-- <style type="text/css"> -->
+ <!-- table.error { border-collapse:collapse; border-style:hidden hidden none hidden } -->
+ <!-- table.error thead { border-bottom:solid } -->
+ <!-- table.error tbody th:first-child { border-left:solid } -->
+ <!-- table.error td, table th { border-left:solid; border-right:solid; border-bottom:solid thin; vertical-align:top; padding:0.2em } -->
+ <!-- </style> -->
+
+</head>
+<body>
+
+ <section id="sotd">
+ This document is not complete.
+ It is subject to major changes and, while early experimentations are encouraged, it is therefore not intended for implementation.
+ </section>
+
+ <section id="abstract">
+ <!-- TODO: are all of the links and objects in the abstract formatted? -->
+ <p>
+ This specification provides an API for representing byte stream in web applications, as well as programmatically building and reading its contents.
+ This includes:
+ </p>
+ <ul>
+ <li>
+ A <a>WritableByteStream</a> interface which defines a protocol for data consuming APIs to communicate with other data producing APIs or code.
+ </li>
+ <li>
+ A <a>ReadableByteStream</a> interface which defines a protocol for data producing APIs to communicate with other data consuming APIs or code.
+ </li>
+ <li>
+ A <a>ByteStream</a> interface which represents a byte sequence which can be read only once and provides APIs for building it, writing data to it, reading and piping data from it.
+ </li>
+ <li>
+ A <a>ByteStreamConsumeResult</a> interface which represents the result of consuming operations such as reading and piping.
+ It holds a chunk of content read from a stream, the number of bytes consumed, and EOF signal.
+ </li>
+ <li>
+ A <a>ByteStreamReadType</a> enum which represents data types as which the <a>ReadableByteStream</a> can be read.
+ </li>
+ <li>
+ A list of notable byte stream <a href="#producers">producers</a> and <a href="#consumers">consumers</a> for which we can apply either or both of <a>ReadableByteStream</a> and <a>WritableByteStream</a> model.
+ </li>
+ <li>
+ Extensions to <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-xmlhttprequest-interface">XMLHttpRequest</a> [[!XMLHTTPREQUEST2]] to add support for uploading data via <a>WritableByteStream</a> and downloading a response as a <a>ReadableByteStream</a>.
+ </li>
+ <li>
+ Extensions to <a href="http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL">URL.createObjectURL</a> and
+ <a href="http://dev.w3.org/2006/webapi/FileAPI/#dfn-revokeObjectURL">URL.revokeObjectURL</a> to add support for <a>ReadableByteStream</a>.
+ </li>
+ </ul>
+
+ <p>
+ This API is designed to be used in conjunction with other APIs and elements on the web platform, notably:
+ <a href="http://dev.w3.org/2006/webapi/FileAPI">File</a> [[!FILE-API]],
+ <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2">XMLHttpRequest</a>
+ (e.g. with an overloaded <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-send-method"><code>send()</code></a> method
+ and <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsetype-attribute"><code>response</code></a> object for <a>ByteStream</a> objects) [[!XMLHTTPREQUEST2]],
+ <a href="http://dev.w3.org/html5/postmsg/#dom-window-postmessage"><code>postMessage</code></a>, and
+ Web Workers [[!WEBWORKERS]].
+ </p>
+ </section>
+
+ <section id="introduction" class="section informative">
+ <h2>Introduction</h2>
+
+ <p>
+ Web applications should have the ability to acquire and manipulate data in a wide variety of forms, including as a sequence of data made available over time.
+ This specification defines the basic representation for byte streams, and programmatic ways to create, read, and write to byte streams and errors raised on those operations.
+ </p>
+
+ <p>
+ The <a>WritableByteStream</a> interface defines a protocol for data consuming APIs to communicate with other data producing APIs or code.
+ It provides a <code>write</code> method for writing data
+ to a <a>WritableByteStream</a> as a <a>Blob</a>, <a>ArrayBuffer</a>, or as <a>DOMString</a>,
+ and should happen asynchronously on the user agent’s main thread.
+ </p>
+
+ <p>
+ The <a>ReadableByteStream</a> interface defines a protocol for data producing APIs to communicate with other data consuming APIs or code.
+ It provides a <code>read</code> method for reading data
+ from a <a>ReadableByteStream</a> as a <a>ByteStreamConsumeResult</a>, which provides the data as a <a>Blob</a>, <a>ArrayBufferView</a>, or as <a>DOMString</a>,
+ and should happen asynchronously on the user agent’s main thread. Additionally, the stream can also be used in API <a href="#consumers">consumers</a> such as a media element.
+ </p>
+
+ <p>
+ The <a>ByteStream</a> interface represents binary data which can be obtained over time and read once. A <a>ByteStream</a> can come from API <a href="#producers">producers</a> such as <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-xmlhttprequest-interface"><code>XMLHttpRequest</code></a>, or can
+ be built using the <a>ByteStream</a> constructor.
+ Producer APIs themselves can implement the <a>ReadableByteStream</a> interface.
+ </p>
+
+ <p>
+ An asynchronous API for reading <a>ReadableByteStreams</a> prevents blocking and UI "freezing" on a user agent’s main thread
+ This specification defines an asynchronous API to access a <a>ByteStream</a>. Error conditions that may arise during reading of a <a>ByteStream</a> will be handled by a reject callback set to the promise returned by the read() method. An example will be illustrative.
+ </p>
+
+ <p>
+ In the example below, different code blocks handle progress, error, and success conditions.
+ The example demonstrates how to read a chunk of data from a <a>ByteStream</a> using <code>read</code>. The <a>ByteStream</a> may of come from a <a href="#producers ">producer</a> such as <code>XMLHttpRequest</code>. Additionally, it demonstrates how to read a stream until an EOF is encountered.
+ </p>
+
+ <pre class="example">
+// Read the first 1024 bytes of the stream as UTF-8
+stream.readEncoding = "UTF-8";
+stream.readType = "arraybuffer";
+Promise readPromise = stream.read(1024);
+readPromise.then(
+ function(result) {
+ console.log("Loaded" + result.size + " bytes");
+ // Handle result.data
+ },
+ function(error) {
+ // Handle error
+ }
+);
+
+// Read data from the stream repeatedly
+function readUntilEof() {
+ stream.read(1024).then(
+ function(result) {
+ // Handle read data
+ someProcessFunction(result.data);
+
+ // Print progress
+ someReportFunction(result.size);
+
+ if (!result.eof) {
+ readUntilEof();
+ }
+ },
+ function(error) {
+ // Handle error
+ }
+ );
+}</pre>
+
+ <p>
+ In the example below, different code blocks handle progress, error, and success conditions.
+ The example below demonstrates how to obtain a <a>ReadableByteStream</a> from <a>XMLHttpRequest</a> to begin playing a large video in <code>readystate</code> LOADING.
+ The example takes the <a>ReadableByteStream</a> from a <a href="#producers">producer</a>, <a>XMLHttpRequest</a>, and gives to a <a href="#consumers">consumer</a>, the video tag.
+ </p>
+
+ <pre class="example">
+function handler() {
+ if(this.readyState == this.LOADING) {
+ var theStream = this.response;
+ var streamURL = URL.createObjectURL(theStream);
+ document.getElementById("myVideoTag").src = streamURL;
+ }
+}
+
+var client = new XMLHttpRequest();
+client.onreadystatechange = handler;
+client.setRequestHeader('customHeader', 'value');
+client.setRequestHeader('customHeader2', 'value2');
+client.open("GET", "myvideo.h264");
+client.responseType = "stream";
+client.send();</pre>
+
+ <p>
+ In addition to the <a>ReadableByteStream</a> interface, this specification introduces an interface called <a>WritableByteStream</a> for data consuming APIs.
+ The <a>WritableByteStream</a> interface provides a <code>write()</code> method which allows applications to write data to the data consuming API as listed in <a href="#consumers">consumer</a>.
+ <code>write()</code> supports writing bytes represented as a <a>Blob</a>, <a>ArrayBuffer</a>, or <a>DOMString</a>.
+ </p>
+ <p>
+ The example below demonstrates how to use <code>write()</code> to load a Stream into the audio tag, whose data could be processed and built dynamically at read time.
+ </p>
+
+ <pre class="example">
+var theStream = new Stream("audio/mp3");
+
+function writeData(){
+ var moreData;
+ // Do work to create more data to place into the stream
+
+ // If we have no more data to process and place in the stream, we close
+ if (moreData == null){
+ theStream.close();
+ } else{
+ theStream.write(moreData).then(
+ function () {
+ writeData();
+ },
+ function (error) {
+ // Handle error
+ }
+ );
+ }
+}
+
+var streamURL = URL.createObjectURL(theStream);
+document.getElementById('audioTag').src = streamURL;
+
+writeData();</pre>
+ </section>
+
+ <section class="section" id="writableByteStream">
+ <h2>WritableByteStream interface</h2>
+
+ <p>
+ The WritableByteStream interface defines a protocol for APIs that consume byte stream how to receive byte stream and notify the writer of completion of receiving and how much data it can receive currently.
+ By returning a Promise and delaying fulfillment of it, the WritableByteStream realizes flow control.
+ </p>
+
+ <dl class="idl" title="interface WritableByteStream">
+ <dt>Promise write()</dt>
+ <dd>
+ <p>
+ If <var>data</var> is a <a>DOMString</a>, <a>ArrayBufferView</a> or <a>Blob</a>, this method writes the specified <var>data</var> to the WritableByteStream.
+ Fulfillment or rejection of the returned Promise indicates completion of the write() method call.
+ Incomplete write() operations are queued in the WritableByteStream.
+ The returned Promise will be fulfilled with the number of bytes written to the WritableByteStream.
+ </p>
+
+ <p>
+ If <var>data</var> is an unsigned long long value, this method waits until the WritableByteStream becomes able to accept the specified number of bytes.
+ The returned Promise will be fulfilled with the number of bytes the WritableByteStream can accept.
+ </p>
+
+ <p>
+ If <var>data</var> is undefined, this method waits until the WritableByteStream becomes able to accept any non-zero amount of data.
+ The returned Promise will be fulfilled with the number of bytes the WritableByteStream can accept.
+ </p>
+
+ <dl class="parameters">
+ <dt>(DOMString or ArrayBufferView or Blob or unsigned long long)? data</dt>
+ <dd>Data to write or the number of bytes the WritableByteStream can accept.</dd>
+ </dl>
+ </dd>
+
+ <dt>Promise close()</dt>
+ <dd>
+ <p>
+ This method tells the WritableByteStream that no more data will be written to it.
+ This is an irreversible operation.
+ Once close() has been called on a WritableByteStream, no more write() or close() call must be made on it.
+ </p>
+ </dd>
+ </dl>
+ </section>
+
+ <section class="section" id="readableByteStream">
+ <h2>ReadableByteStream interface</h2>
+
+ <p>
+ The ReadableByteStream interface defines a protocol for APIs that produces byte stream how to receive a read request from the reader and output byte stream.
+ By returning a Promise and delaying fulfillment of it, the ReadableByteStream realizes asynchronous data consumption.
+ </p>
+
+ <dl class="idl" title="interface ReadableByteStream">
+ <dt>attribute ByteStreamReadType readType</dt>
+ <dd>
+ <p>
+ Specifies the type of data to receive data read from the ReadableByteStream by a <code>read()</code> method call.
+ This can be set to the empty <a>DOMString</a> (default), "arraybuffer", "blob", "text" or "none" to change the type of the read operation.
+ </p>
+ </dd>
+
+ <dt>attribute DOMString readEncoding</dt>
+ <dd>
+ <p>
+ Specifies a <a>DOMString</a> that represents the label of an encoding [[!EncodingDetermination]].
+ If set, it will be used as part of the encoding determination used when processing a <code>read</code> method call.
+ If not set, it will return the empty <a>DOMString</a>.
+ </p>
+ </dd>
+
+ <dt>Promise read()</dt>
+ <dd>
+ <p>
+ This method reads data from the ReadableByteStream.
+ This method takes an optional <var>size</var> argument which represents the number of bytes to be read.
+ Another read() or pipe() call must not be made until the returned Promise is resolved or rejected.
+ The user agent must run the steps below (unless otherwise indicated):
+ </p>
+
+ <dl class="parameters">
+ <dt>optional [Clamp] unsigned long long size</dt>
+ <dd>Number of bytes to read.</dd>
+ </dl>
+ </dd>
+
+ <dt>Promise pipe()</dt>
+ <dd>
+ <p>
+ This method transfers bytes from the ReadableByteStream to a <a>WritableByteStream</a>.
+ This method takes a <var>destination</var> argument and optionally a <var>size</var> argument.
+ Another read() or pipe() call must not be made until the returned <a>Promise</a> is fulfilled or rejected.
+
+ <dl class="parameters">
+ <dt>!(<a>WritableByteStream</a> or <a>WritableByteStream</a>[]) destination</dt>
+ <dd>Destination <a>WritableByteStream</a>.</dd>
+ <dt>optional [Clamp] unsigned long long size</dt>
+ <dd>Number of bytes to transfer.</dd>
+ </dl>
+ </p>
+
+ <p>
+ Note that fulfillment or rejection of the returned Promise doesn't necessarily mean that the data transferred to the destination Stream has been successfully read from the Stream.
+ </p>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section class="section" id="streams">
+ <h2>ByteStream</h2>
+
+ <p>
+ This section introduces the <code>ByteStream</code> interface, as well as accompanying interfaces required as part of the <a>ByteStream</a> implementation.
+ This includes a constructor to build a <a>ByteStream</a> object, implementation of <a>WritableByteStream</a> and <a>ReadableByteStream</a> and the type attribute.
+ </p>
+
+ <section class="section" id="stream-interface">
+ <h2>ByteStream Interface</h2>
+
+ <p>
+ This interface represents a sequence of bytes which can be read only once over time.
+ Contents of a ByteStream can be stored in memory or backed by slower devices such as a hard disk.
+ </p>
+ <p>
+ It provides a <a href="#widl-ByteStream-type">type</a> attribute which represents the type of data in the Stream.
+ </p>
+ <p>
+ It also provides the ability to read and write the contents of the Stream.
+ </p>
+
+ <p>
+ A ByteStream is an object that:
+ <ul>
+ <li>Has a content type</li>
+ <li>Has unspecified length</li>
+ <li>Data is read first in, first out</li>
+ <li>Once data is read from it, the data is removed and can no longer be re-read</li>
+ </ul>
+ </p>
+
+ <p>
+ A ByteStream object inherits the <a>WritableByteStream</a> and <a>ReadableByteStream</a> interface and satisfies requirements for them.
+ </p>
+
+ <p>
+ A ByteStream has an associated integer value called <dfn>minWindow</dfn>.
+ </p>
+
+ <p>
+ A ByteStream has an associated integer value called <dfn>window</dfn>.
+ This value limits the number of bytes bufferred in the ByteStream.
+ This value equals to <code>max(<a>pullAmount</a>, <a>minWindow</a>)</code> where <dfn>pullAmount</dfn> is sum of non-undefined size argument of pending read() and pipe() calls on this ByteStream.
+ </p>
+
+ <p>
+ A Stream holds a sequence of bytes possibly terminated by a terminator.
+ <dfn id="write-to-stream">Writing bytes to a ByteStream</dfn> means appending the bytes to the sequence.
+ <dfn id="terminate-stream">Terminating a ByteStream</dfn> means appending a terminator to the sequence.
+ <dfn id="read-from-stream">Reading bytes from a ByteStream</dfn> pops bytes from the head of the sequence.
+ If a terminator is encountered while reading bytes from a Stream, it is said <dfn id="eof-reached">the EOF is reached</dfn>.
+ This sequence is internal, so scripts cannot access it directly.
+ </p>
+
+ <p>
+ When <var>N</var> bytes of data are written to the sequence, it consumes <var>N</var> from <a>window</a>.
+ When <var>N</var> bytes of data are read from the sequence, it frees <var>N</var> to <a>window</a>.
+ </p>
+
+ <p>
+ A ByteStream object has an associated <dfn>pending write queue</dfn>.
+ Arguments of write() method call is queued to this queue.
+ As <a>window</a> becomes available, the data given to the write() is written to the sequence consuming window.
+ Once all data of the write() is written, the Promise returned for the write() is fulfilled.
+ This queue is internal, so scripts cannot access it directly.
+ </p>
+
+ <dl class="idl" title="interface ByteStream">
+ <dt>Constructor()</dt>
+ <dd>
+ Constructs a <a>ByteStream</a> and sets the <a href="#widl-ByteStream-type">type</a> to the specified value.
+ <dl class="parameters">
+ <dt>in unsigned long long minWindow</dt>
+ <dd>
+ Specifies the initial value of <a>minWindow</a>.
+ </dd>
+ <dt>in optional DOMString type</dt>
+ <dd>
+ Specifies the MIME type [[!RFC2046]] of the <a>ByteStream</a>.
+ </dd>
+ </dl>
+ </dd>
+
+ <dt>Promise write()</dt>
+ <dd>
+ <p>
+ The user agent must run the steps below (unless otherwise indicated):
+
+ <ol>
+ <li>
+ If the <a>ByteStream</a> has been neutered, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ If the <a>write closed flag</a> is set, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ Let <var>writePromise</var> be a new promise.
+ </li>
+ <li>
+ Return <var>writePromise</var>, but continue to process the steps in this algorithm.
+ </li>
+ <li>
+ If no <a>window</a> is available, queue the write() operation to <a>write pending queue</a> and wait for <a>window</a> becomes available.
+
+ Execute the rules below, depending on the type of <code>data</code>:
+
+ <dl class="switch">
+ <dt><code>ArrayBufferView</code></dt>
+ <dd>
+ Let <code>rawData</code> be the raw data represented by the <code>Blob</code> object.
+ </dd>
+ <dt><code>Blob</code></dt>
+ <dd>
+ Let <code>rawData</code> be the data stored in the section of the buffer described by the <code>ArrayBuffer</code> object that the <code>ArrayBufferView</code> object references.
+ </dd>
+ <dt><code>DOMString</code></dt>
+ <dd>
+ Let <code>rawData</code> be the result of <a href="http://encoding.spec.whatwg.org/#encode">encoding</a> <code>data</code> to binary data using the encoding determined by the [[!EncodingDetermination]].
+ </dd>
+ </dl>
+ </li>
+ <li>
+ <a href="#write-to-stream">Write <code>rawData</code> to the Stream</a>.
+ </li>
+ <li>
+ If an error has occurred during the write, neuter the <a>ByteStream</a>, let <code>exception</code> be an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and run <code>Reject(<code>writePromise</code>, <code>exception</code>)</code> as specified in the promises spec and terminate this algorithm.
+ <li>
+ Once all bytes are written, remove the write() from <a>write pending queue</a> and run <code>Resolve(<code>writePromise</code>, <code>undefined</code>)</code> as specified in the promises spec.
+ Implementations may delay this step if appropriate.
+ </li>
+ </ol>
+ </p>
+ <p>
+ Note that completion of write() doesn't necessarily mean that the data written to the Stream has been successfully read.
+ </p>
+ <dl class="parameters">
+ <dt>(DOMString or ArrayBufferView or Blob or unsigned long long)? data</dt>
+ <dd>Data to write or available <a>window</a> size.</dd>
+ </dl>
+ </dd>
+
+ <dt>Promise close()</dt>
+ <dd>
+ <p>
+ When all data has been read from the <a>ByteStream</a> on which close() has been called, i.e. <a href="#eof-reached">EOF is reached</a>, it resolves the Promise returned by read() with a <a>ByteStreamConsumeResult</a> with the <a href="#widl-ByteStreamConsumeResult-eof">eof</a> attribute set to true.
+ The user agent must run the steps below:
+ </p>
+
+ <ol>
+ <li>
+ If the <a>ByteStream</a> has been neutered, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ If the <a>write closed flag</a> is set, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ Set the <a>write closed flag</a>.
+ </li>
+ <li>
+ Let <var>closePromise</var> be a new <a>Promise</a> and return it but keep processing the following algorithm.
+ </li>
+ <li>
+ Wait until <a>write pending queue</a> becomes empty.
+ </li>
+ <li>
+ <a href="#terminate-stream">Terminate the Stream</a>.
+ </li>
+ <li>
+ If an error has occurred during writing a stream termination, neuter the <a>ByteStream</a> and terminate these steps.
+ </li>
+ </ol>
+ </dd>
+
+ <dt>readonly attribute DOMString type</dt>
+ <dd>
+ Returns the ASCII-encoded string in lower case representing the media type of the <code>Stream</code>,
+ expressed as an RFC2046 MIME type [[!RFC2046]].
+ Conforming user agents SHOULD return the MIME type of the <code>Stream</code>, if it is known.
+ If conforming user agents cannot determine the media type of the <code>Stream</code>, they MUST return the empty string.
+ A string is a valid MIME type if it matches the media-type token defined in section 3.7 "Media Types" of RFC 2616 [[!HTTP11]].
+ </dd>
+
+ <dt>attribute <a>ByteStreamReadType</a> readType</dt>
+ <dd>
+ <p>
+ Returns the type of the last read operation taken on the <a>ByteStream</a>.
+ On getting, conforming user agents must return the type of the last read operation. If no read operation has taken place and the <code>readType</code> was not set, then return the empty string. This can be set to the empty string (default), "arraybuffer", "blob" and "text" to change the type of the read operation.
+ </p>
+ </dd>
+
+ <dt>attribute DOMString readEncoding</dt>
+ <dd>
+ <p>
+ A <code>DOMString</code> that represents the label of an encoding [[!EncodingDetermination]]. If set, it will be used as part of the encoding determination used when processing a <code>read</code> call. If not set, it will return the empty string.
+ </p>
+ </dd>
+
+ <dt>Promise read()</dt>
+ <dd>
+ <p>
+ This method reads data from the <a>ByteStream</a>.
+ This method takes an optional <var>size</var> argument which represents the number of bytes to be read.
+ Another read() or pipe() call must not be made until the returned Promise is resolved or rejected.
+ The user agent must run the steps below (unless otherwise indicated):
+ </p>
+
+ <ol>
+ <li>
+ If the <a>ByteStream</a> has been neutered, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ If the <a>read pending flag</a> is set, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ If <code>size</code> is specified but is 0, throw a "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#syntaxerror">SyntaxError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ Set the <a>read pending flag</a>.
+ </li>
+ <li>
+ Let <code>readPromise</code> be a new promise.
+ </li>
+ <li>
+ Return <code>readPromise</code>, but continue to process the steps in this algorithm.
+ </li>
+ <li>
+ If <code>size</code> is specified, <a href="#read-from-stream">read data from the Stream</a> until <code>size</code> bytes are read.
+ </li>
+ <li>
+ Otherwise, <a href="#read-from-stream">read data from the Stream</a> until any non-zero bytes are read.
+ </li>
+ <li>
+ If an error has occurred during reading, neuter the <a>ByteStream</a>, let <code>exception</code> be an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and run <code>Reject(<code>readPromise</code>, <code>exception</code>)</code> as specified in the promises spec and terminate these steps.
+ </li>
+ <li>
+ Let <code>result</code> be a newly created <a>ByteStreamConsumeResult</a>.
+ </li>
+ <li>
+ If EOF is reached, set the <a href="#widl-ByteStreamConsumeResult-eof">eof</a> attribute of <code>result</code> to true.
+ </li>
+ <li>
+ Otherwise, set the <a href="#widl-ByteStreamConsumeResult-eof">eof</a> attribute of <code>result</code> to false.
+ </li>
+ <li>
+ Set the <a href="#widl-ByteStreamConsumeResult-eof">data</a> attribute of <code>result</code> to the result of executing the steps below.
+ <dl class="switch">
+ <dt>If <a href="#widl-ByteStream-readType">readType</a> is the empty string or "<code title>text</code>"</dt>
+ <dd>
+ <ol>
+ <li>
+ If readEncoding is not null, let <var>charset</var> be <code>readEncoding</code>.
+ </li>
+ <li>
+ Otherwise, let <var>charset</var> be utf-8.
+ </li>
+ <li>
+ Let <code>result</code> be result of <a href="http://encoding.spec.whatwg.org/#decode">decoding</a> the data read using fallback encoding <var>charset</var>.
+ </li>
+ </ol>
+ </dd>
+ <dt>If <a href="#widl-ByteStream-readType">readType</a> is the empty string or "<code title>blob</code>"</dt>
+ <dd>
+ Let <code>result</code> be a blob created from the read data.
+ </dd>
+ <dt>If <a href="#widl-ByteStream-readType">readType</a> is the empty string or "<code title>arraybuffer</code>"</dt>
+ <dd>
+ Let <code>result</code> be an array buffer created from the read data.
+ </dd>
+ </dl>
+ </li>
+ <li>
+ Unset the <a>read pending flag</a> and run <code>Resolve(<code>readPromise</code>, <code>result</code>)</code> as specified in the promises spec.
+ </li>
+ </ol>
+ <dl class="parameters">
+ <dt>optional [Clamp] unsigned long long size</dt>
+ <dd>Number of bytes to read.</dd>
+ </dl>
+ </dd>
+
+ <dt>Promise pipe()</dt>
+ <dd>
+ <p>
+ This method transfers data from the <a>ByteStream</a> to another Stream.
+ This method takes a <code>destinations</code> and optionally a <code>size</code>.
+ Another read(), skip() or pipe() call must not be made until the returned Promise is resolved or rejected.
+ Resolution of the returned Promise doesn't necessarily mean that the data transferred to the destination Stream has been successfully read from the Stream.
+ The user agent must run the steps below:
+
+ <ol>
+ <li>
+ If the <a>ByteStream</a> has been neutered, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ If the <a>read pending flag</a> is set, throw an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ If <code>size</code> is specified but is 0, throw a "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#syntaxerror">SyntaxError</a></code>" [[!DOM4]] exception and terminate these steps.
+ </li>
+ <li>
+ If <code>destinations</code> is a <a>ByteStream</a>, let <code>destinations</code> instead be an array consisting of just that <a>ByteStream</a>.
+ </li>
+ <li>
+ Set the <a>read pending flag</a>.
+ </li>
+ <li>
+ Let <code>readPromise</code> be a new promise.
+ </li>
+ <li>
+ Return the pipe() method with <code>readPromise</code>, but continue to process the steps in this algorithm.
+ </li>
+ <li>
+ If <code>size</code> is specified, <a href="#read-from-stream">read data from the stream</a> until <code>size</code> bytes are read.
+ </li>
+ <li>
+ Otherwise, <a href="#read-from-stream">read data from the Stream</a> until <a href="#eof-reached">EOF is reached</a>.
+ </li>
+ <li>
+ As read data becomes available, <a href="#write-to-stream">write newly read data to <code>destinations</code></a>.
+ </li>
+ <li>
+ If any error has occurred during reading or writing to <code>destinations</code>, neuter the <a>ByteStream</a>, let <code>exception</code> be an "<code><a href="http://dev.w3.org/2006/webapi/DOM4Core/#invalidstateerror">InvalidStateError</a></code>" exception and run <code>Reject(<code>readPromise</code>, <code>exception</code>)</code> as specified in the promises spec and terminate these steps.
+ </li>
+ <li>
+ Once read and write are both completed for all destination streams, run the following algorithm:
+ <ol>
+ <li>
+ Let <code>result</code> be a newly created <a>ByteStreamConsumeResult</a> object.
+ </li>
+ <li>
+ If <a href="#eof-reached">EOF is reached</a>, set <a href="#widl-ByteStreamConsumeResult-eof">eof</a> attribute of <code>result</code> to true.
+ </li>
+ <li>
+ Otherwise, set <a href="#widl-ByteStreamConsumeResult-eof">eof</a> attribute of <code>result</code> set to false.
+ </li>
+ <li>
+ Set <a href="#widl-ByteStreamConsumeResult-size">size</a> attribute of <code>result</code> to the total size of the read data.
+ </li>
+ <li>
+ Unset the <a>read pending flag</a> and run <code>Resolve(<code>readPromise</code>, <code>result</code>)</code> as specified in the promises spec.
+ </li>
+ </ol>
+ </li>
+ </ol>
+ <dl class="parameters">
+ <dt>in !(WritableByteStream or WritableByteStream[]) destination</dt>
+ <dd>Destination <a>WritableByteStream</a>.</dd>
+ <dt>optional [Clamp] unsigned long long size</dt>
+ <dd>Number of bytes to transfer.</dd>
+ </dl>
+ </p>
+ </dd>
+ </dl>
+ </section>
+
+ <section class="section" id="streamConsumeResult-interface">
+ <h2>ByteStreamConsumeResult Interface</h2>
+
+ <p>
+ ByteStreamConsumeResult represents the result of read() or pipe() method call.
+ </p>
+
+ <p>
+ It's named as ByteStreamConsumeResult to avoid confusion since it's used for both read() and pipe().
+ </p>
+
+ <dl class="idl" title="interface ByteStreamConsumeResult">
+ <dt>readonly attribute boolean eof</dt>
+ <dd>specifies if the given read resulted in an EOF for the <a>ByteStream</a></dd>
+ <dt>readonly attribute any data</dt>
+ <dd>The contents of the read request</dd>
+ <dt>readonly attribute unsigned long long size</dt>
+ <dd>The size, in bytes, of the data read</dd>
+ </dl>
+ </section>
+
+ <section class="section" id="streamReadType-interface">
+ <h2>ByteStreamReadType enum</h2>
+
+ <p>
+ Data can be read as various data types from ReadableByteStream.
+ The ByteStreamReadType enum defines DOMString values to specify the data types.
+ "none" is useful when seeking data by skipping some amount of data.
+ User agents may implement some optimization for "none" type read for example omitting internal data transfer.
+ </p>
+
+ <dl class="idl" title="enum ByteStreamReadType">
+ <dt>blob</dt>
+ <dd>Read operations should return data as a Blob</dd>
+ <dt>arraybuffer</dt>
+ <dd>Read operations should return data as an ArrayBuffer</dd>
+ <dt>text</dt>
+ <dd>Read operations should return data as a DOMString</dd>
+ <dt>none</dt>
+ <dd>Read operations should return nothing</dd>
+ </dl>
+ </section>
+
+ <section class="section" id="error-uris_for_streams">
+ <h3>URIs for Stream</h3>
+ <p>
+ To reference a <a>ByteStream</a>, <a href="http://dev.w3.org/2006/webapi/FileAPI/#url">the same URI used</a> for <code>Blobs</code> and <code>Files</code> in
+ <a href="http://dev.w3.org/2006/webapi/FileAPI/#url">6.7. A URI for Blob and File reference</a> of
+ the File API specification should be used. [[!FILE-API]]
+ The definitions of <strong>Origin</strong>, <strong>Lifetime</strong>, <strong>Referencing</strong>, and <strong>Dereferencing</strong> of a <code>Blob</code> should be applied to a <a>ByteStream</a>.
+ </p>
+
+ <section class="section" id="creating-revoking-streamuri">
+ <h4>Creating and Revoking a Stream URI</h4>
+ <p>
+ A <dfn id="stream-uri">Stream URI</dfn> is a <code>Blob URI</code> that is referencing a <a>ByteStream</a>.
+ These URIs are created and revoked using methods exposed on the URL object,
+ as defined in <a href="http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking">6.7.5. Creating and Revoking a Blob URI</a>
+ of the File API specification. [[!FILE-API]]
+ </p>
+ <p>
+ <a href="http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL">URL.createObjectURL</a>
+ and <a href="http://dev.w3.org/2006/webapi/FileAPI/#dfn-revokeObjectURL">URL.revokeObjectURL</a>
+ should both be extended as follows:
+ </p>
+ <dl class="idl" title="interface URL">
+ <dt>static DOMString? createObjectURL(in (Blob or ReadableByteStream) object)</dt>
+ <dd>
+ <p>
+ The extension onto <code>createObjectURL</code> should have the following steps added.
+ </p>
+ <p>
+ Returns a unique Blob URL each time it is called on a valid <code>object</code> argument, which is a non-null <a>ByteStream</a> in scope of the global object's URL property from which this static method is called. This method must act as follows:
+ <ol>
+ <li>
+ If called with a <code>Stream</code> argument that is NOT valid, then user agents must return null.
+ </li>
+ <li>
+ If called with a valid <code>Stream</code> argument,
+ user agents must run the following sub-steps:
+ <ol>
+ <li>
+ If the <a>read pending flag</a> of the <a>ByteStream</a> is set, return null.
+ </li>
+ <li>
+ Set the <a>read pending flag</a> of the <a>ByteStream</a>.
+ </li>
+ <li>
+ Return a unique <code>Blob URI</code> that can be used to dereference the <code>stream</code> argument.
+ </li>
+ <li>
+ Add an entry to the Blob URL Store for this Blob URL.
+ </li>
+ </ol>
+ </li>
+ </ol>
+ </p>
+ </dd>
+
+ <dt>static DOMString? createFor(in (Blob or ReadableByteStream) object)</dt>
+ <dd>
+ <p>
+ The extension onto <code>createFor</code> should have the following steps added.
+ </p>
+ <p>
+ Returns a unique Blob URL each time it is called on a valid <code>object</code> argument, which is a non-null <a>ByteStream</a> in scope of the global object's URL property from which this static method is called. Blob URLs created with this method are said to be auto-revoking since user-agents are responsible for the revocation of Blob URLs created with this method, subject to the lifetime stipulation for Blob URLs. This method must act as follows:
+ <ol>
+ <li>
+ If called with a <code>Stream</code> argument that is NOT valid, then user agents must return null.
+ </li>
+ <li>
+ If called with a valid <code>Stream</code> argument,
+ user agents must run the following sub-steps:
+ <ol>
+ <li>
+ If the <a>read pending flag</a> of the <a>ByteStream</a> is set, return null.
+ </li>
+ <li>
+ Set the <a>read pending flag</a> of the <a>ByteStream</a>.
+ </li>
+ <li>
+ Return a unique <code>Blob URI</code> that can be used to dereference the <code>stream</code> argument.
+ </li>
+ <li>
+ Add an entry to the Blob URL Store for this Blob URL.
+ </li>
+ <li>
+ Add an entry in the Revocation List for this Blob URL.
+ </li>
+ </ol>
+ </li>
+ </ol>
+ </p>
+ </dd>
+
+ <dt>static void revokeObjectURL(in DOMString url)</dt>
+ <dd>
+ <p>
+ The extension onto <code>revokeObjectURL</code> should have the following steps added.
+ </p>
+ <ol>
+ <li>
+ If the URL refers to a <code>Blob</code> or <code>Stream</code> that is both
+ valid and in the same origin of the global object’s <code>URL</code> property on which this static method was called,
+ user agents MUST return a 404 response code when the URL is dereferenced.
+ </li>
+ <li>
+ If the URL refers to a <code>Blob</code> or <code>Stream</code> that is <strong>not</strong> valid
+ or if the value provided for the URL argument is not a <code>Blob URI</code>
+ or if the URL argument refers to a <code>Blob</code> or <code>Stream</code> that is <strong>not</strong> in the same origin
+ as the global object’s <code>URL</code> property, this method call does nothing.
+ User agents MAY display a message on their error console.
+ </li>
+ </ol>
+ </dd>
+ </dl>
+ </section>
+ </section>
+ </section>
+
+ <section class="section" id="producers-consumers">
+ <h2>Stream Consumers and Producers</h2>
+ <p>
+ Streams can be both produced and consumed by various APIs. APIs which create streams are identified as producers, and ones which read and act on a stream are known as consumers. This section identifies some of the APIs where Streams may be produced and consumed.
+ <section class="note">The list of producers and consumers below is not an exhaustive list. It is placed here as informative for the time being.</section>
+ </p>
+ <section class="section" id="consumers">
+ <h2>Stream Consumers</h2>
+ <p>This section outlines APIs which can consume a Stream object</p>
+ <ul>
+ <li>WebAudio</li>
+ <li>MediaSourceExtensions</li>
+ <li>WebCrypt</li>
+ <li>TextEncoder</li>
+ <li>TextDecoder</li>
+ <li>WebSockets</li>
+ </ul>
+ </section>
+
+ <section class="section" id="producers">
+ <h2>Stream Producers</h2>
+ <p>This section outlines APIs which can produce a Stream object</p>
+ <ul>
+ <li>XMLHttpRequest</li>
+ <li>FileReader</li>
+ <li>Media Capture</li>
+ <li>Media Recording API</li>
+ <li>IndexedDB</li>
+ <li>WebCrypt</li>
+ <li>TextEncoder</li>
+ <li>TextDecoder</li>
+ <li>WebSockets</li>
+ <li>EventSource</li>
+ </ul>
+ </section>
+ </section>
+
+ <section class="section" id="security">
+ <h2>Security Considerations</h2>
+ <p>
+ A <a>ByteStream</a> should have the same security considerations as a <code>Blob</code>.
+ This is outlined in <a href="http://dev.w3.org/2006/webapi/FileAPI/#security-discussion">6.8. Security Considerations</a>
+ of the File API specification. [[!FILE-API]]
+ Because a <a>ByteStream</a> uses a <code>Blob URI</code>, cross origin requests on a <a>ByteStream</a> will not be supported.
+ </p>
+ </section>
+
+ <section class="section" id="XMLHttpRequest">
+ <h2>Extension of XMLHttpRequest</h2>
+ <p>
+ This specification proposes an extension to <code>XMLHttpRequest</code> [[!XMLHTTPREQUEST2]] to add support for <a>ByteStream</a>. This section is temporary and is meant to provide a recommendation for how <a>ByteStream</a> should be incorporated into <code>XMLHttpRequest</code>.
+ This will extend <code>XMLHttpRequest</code> to allow for receiving and uploading of a <a>ByteStream</a>.
+ One such scenario is providing access to data during <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-readystate"><code>readyState</code></a> 3 (LOADING).
+ The sections below document in detail what extensions must be done to <code>XMLHttpRequest</code> to support <a>ByteStream</a>.
+ </p>
+
+ <section class="section" title="addition-of-stream-response-entity">
+ <h3>Addition of stream response entity body</h3>
+ <p>
+ <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#response-entity-body-0">The section named "Response Entity Body"</a>
+ in XMLHttpRequest specification [[!XMLHTTPREQUEST2]] should have the following additions:
+ </p>
+ <p>
+ The <dfn id="stream-response-entity">stream response entity body</dfn> is either a <a>ByteStream</a> representing the <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#response-entity-body">response entity body</a> or null.
+ If the <a href="#stream-response-entity">stream response entity body</a> is null, let it be the return value of the following algorithm:
+ </p>
+ <ol>
+ <li>
+ If the <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#response-entity-body">response entity body</a> is null,
+ return an empty <a>ByteStream</a> object.
+ </li>
+ <li>
+ Return a <a>ByteStream</a> object representing the <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#response-entity-body">response entity body</a>.
+ </li>
+ </ol>
+ </section>
+
+ <section class="section" title="addition-of-stream">
+ <h3>Addition of "<code>stream</code>" responseType</h3>
+ <p>
+ A new value for the <code>responseType</code> attribute "<code>stream</code>" should be introduced.
+ </p>
+ <p>
+ In the IDL list in <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#interface-xmlhttprequest">the section named "Interface XMLHttpRequest"</a> in XMLHttpRequest specification [[!XMLHTTPREQUEST2]], the definition of <code>XMLHttpRequestResponseType</code> enum should now read:
+ <pre>
+enum XMLHttpRequestResponseType {
+ "",
+ "arraybuffer",
+ "blob",
+ "stream",
+ "document",
+ "json",
+ "text"
+}</pre>
+ </p>
+ </section>
+
+ <section class="section" title="modification-on-response-algorithm">
+ <h3>Modification on the <code>response</code> attribute</h3>
+ <p>
+ The algorithm of the <code>response</code> attribute should be modified to handle the new <code>responseType</code> value "<code>stream</code>".
+ A Stream is binary data obtained sequentially over time.
+ Given this, a <a>ByteStream</a> should be accessible in <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-readystate"><code>readyState</code></a> 3 (LOADING).
+ </p>
+ <p>
+ <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-response-attribute">The section named "The response attribute"</a> in XMLHttpRequest specification [[!XMLHTTPREQUEST2]] should now read:
+ </p>
+ <p>
+ The <code>response</code> attribute must return the result of running these steps:
+ </p>
+ <dl class="switch">
+ <dt>If <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-responsetype"><code>responseType</code></a> is the empty string or "<code>text</code>"</dt>
+ <dd>
+ The same as the original XMLHttpRequest specification.
+ </dd>
+ <dt>If <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-responsetype"><code>responseType</code></a> is "<code>stream</code>"</dt>
+ <dd>
+ <ol>
+ <li>
+ If the state is not <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-loading">LOADING</a> or
+ <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-done">DONE</a>, return null.
+ </li>
+ <li>
+ If the <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#error-flag">error flag</a> is set, return null.
+ </li>
+ <li>
+ Return the <a href="#stream-response-entity">stream response entity body</a>.
+ </li>
+ </ol>
+ </dd>
+ <dt>Otherwise</dt>
+ <dd>
+ The same as the original XMLHttpRequest specification.
+ </dd>
+ </dl>
+ </section>
+
+ <section class="section" id="modification-on-send-algorithm">
+ <h3>send()</h3>
+ <p>
+ The switch in otherwise case of step 4 of
+ <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send()-method">The section named "The <code>send()</code> method"</a>
+ in XMLHttpRequest specification [[!XMLHTTPREQUEST2]] should have the following additions:
+ </p>
+ <dl class="switch">
+ <dt><a>ByteStream</a></dt>
+ <dd>
+ <p>
+ If the object's <a href="#widl-ByteStream-type">type</a> attribute is not the empty string let <var>mime type</var> be its value.
+ </p>
+ <p>
+ Set the <a>read pending flag</a> for the stream.
+ </p>
+ <p>
+ Let the <a href="https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#request-entity-body">request entity body</a> be the raw data represented by <var>data</var>.
+ </p>
+ <p>Once the read is completed for the request, call <a href="#widl-ByteStream-close-void">close()</a> on the stream</p>
+ </dd>
+ </dl>
+ </section>
+ </section>
+
+ <section class="section" id="terminology">
+ <h2>Terminology</h2>
+
+ <p>
+ <dfn>ArrayBufferView</dfn> is defined in <a href="http://www.khronos.org/registry/typedarray/specs/latest/">Typed Array specification</a>.
+ </p>
+
+ <p>
+ <dfn>Blob</dfn> is defined in <a href="http://dev.w3.org/2006/webapi/FileAPI/">File API specification</a>.
+ </p>
+
+ <p>
+ <dfn>Promise</dfn> is defined in <a href="https://github.com/domenic/promises-unwrapping/blob/master/README.md">Promise Objects specification</a>.
+ </p>
+
+ <p>
+ <dfn>DOMString</dfn> is defined in <a href="http://www.w3.org/TR/DOM-Level-3-Core/core.html">DOM Level 3 Core specification</a>.
+ </p>
+ </section>
+
+ <section class="section" id="requirements">
+ <h2>Requirements and Use Cases</h2>
+ <p>
+ The <a>ByteStream</a> type allows for completion of several end-to-end experiences. This section covers what the requirements are for this API, and
+ illustrates some use cases.
+ </p>
+ <ul>
+ <li>
+ Begin loading a video through <code>XMLHttpRequest</code> in <code>readyState</code> LOADING
+ <p>
+ Videos can typically be large files that may take a long time to download, and require authentication or certain headers to access.
+ For certain video formats, an application can begin playing the video once the first chunks of data are available, and would not need to wait for the entire video to download.
+ </p>
+ </li>
+ <li>
+ Begin processing the data of a <a>ByteStream</a> as it is being read via <code>XMLHttpRequest</code>
+ <p>
+ If a file format is understood, then an application can make sense of the data as it being made available. For example, a given
+ file may be very large and the application wants to begin processing the data immediately, rather than having to wait for full download of the file.
+ </p>
+ </li>
+ <li>
+ Upload of dynamic runtime data using <a>ByteStream</a> and <code>XMLHttpRequest</code>
+ <p>
+ There are situations where an application may have data to upload once the application is processing. This could involve processing
+ of data an application wants to upload as it is being created. One such case is the upload of GPS coordinates within an application. The
+ coordiantes may constantly change, and the application wants to upload the data as it being collected.
+ </p>
+ </li>
+ <li>
+ Media streaming scenarios using <a>ByteStream</a> and <code>XMLHttpRequest</code>
+ <p>
+ Media streaming scenarios require the ability to quickly receive data over the network and connect it to a media element. An application can successfully accomplish this by receiving a Stream in <code>readyState</code> LOADING and assign it to a media element. This helps avoid the application from having to buffer the data prior to assigning it to a media element.
+ </p>
+ </li>
+ </ul>
+ </section>
+
+ <section class=appendix>
+ <h2>Acknowledgements</h2>
+ <p>
+ Thanks to Eliot Graff for editorial assistance.
+ Special thanks to the W3C.
+ The editor would like to thank
+ Anne van Kesteren,
+ Austin William Wright,
+ Aymeric Vitte,
+ Domenic Denicola,
+ Isaac Schlueter,
+ Jonas Sicking,
+ Kenneth Russell,
+ Yusuke Suzuki,
+ Adrian Bateman
+ for their contributions to this specification.
+ </p>
+ </section>
+
+</body>
+</html>