The W3C Web Applications Working Group has published the first public working draft of the Streams API, used for representing binary data in web applications as a Stream object.

The Streams API will give developers a way to programmatically build a stream and read its contents. The specification defines objects that can be used in threaded web applications for the synchronous reading of a Stream. It is designed to be used alongside other APIs and web elements such as XMLHttpRequest, postMessage, and Web Workers.

The API starts with a Stream interface. This represents a sequence of data that can be read over time. A Stream can come from APIs such as XMLHttpRequest, or can be built using StreamBuilder. The StreamReader interface has methods that you can use to read the contents of a Stream as a Blob, DataURL, ArrayBuffer, or as Text.

The StreamReader interface is designed to run asynchronously on the user agent’s main thread, with an optional synchronous API to be used within threaded web applications. The asynchronous nature when reading Streams means you don’t run the risk of blocking and UI “freezing” on a user agent’s main thread. The event model used to read and access Streams is closely based on the FileReader interface. It provides asynchronous read methods through event handler attributes and the firing of events. The use of events and event handlers means you can set up separate code blocks to monitor the progress of the read and any error conditions that arise during the reading of the Stream.

The next element of the API is a StreamBuilder interface that you can use to create your own stream, pulling the contents from an internal buffer that you’ve created by appending Text, Blobs, or ArrayBuffers.

The API has extensions to XmlHttpRequest so you can use it to upload and download a Stream, and also extends createObjectURL and revokeObjectURL to add support for Stream.