Fwd: Update on Streams API Status

Since the Web RTC group previously expressed interest in WebApps' 
Streams API, please see the following status and plans information from 
the spec's Editors.

If you have any comments, please send them to 

-------- Original Message --------
Subject: 	Update on Streams API Status
Resent-Date: 	Fri, 7 Feb 2014 04:31:48 +0000
Resent-From: 	<public-webapps@w3.org>
Date: 	Thu, 6 Feb 2014 20:31:18 -0800
From: 	ext Feras Moussa <feras.moussa@hotmail.com>
To: 	public-webapps@w3.org <public-webapps@w3.org>
CC: 	domenic@domenicdenicola.com <domenic@domenicdenicola.com>, Takeshi 
Yoshino <tyoshino@google.com>

Hi All,

I wanted to update everyone on the latest plan for moving forward on the 
Streams spec.

For a variety of reasons, there are currently two Streams Specs being 
worked on - one in the W3C, and one in the WHATWG. Each of these specs 
have their strengths and weaknesses, and were looking at problems from 
different perspectives.

After meeting with the WHATWG folks and discussing the various scenarios 
being targeted by the Streams specs as well as other considerations, we 
all agreed that we have the same goals and should work together to get 
alignment and avoid having different implementations.

This is an opportunity to get a strong consistent API which behaves 
similarly across the various platforms, from browsers to servers. We are 
excited with the potential here, because it lets us tell one story.

Moving forward, we've agreed to revise the approach to working on the 
Streams spec as follows:

Create a 'base' Stream spec, which we will work together on. This will 
be seeded with the base of the WHATWG spec, and we will incorporate 
various pieces from either spec as needed.
This base Stream should:
1. Be the lowest primitive that is independent of any platform
2. Be a layer that could make it into the JS language/ES
3. Could be prototyped in JavaScript directly to showcase it
4. Supports the various Stream goals we discussed, such as creation, 
backpressure, read/write behaviors, etc.

In addition to the base Stream spec, the remaining platform-specific 
pieces which do not fit into the shared-base spec will live in an 
independent spec. This includes things such as support in other APIs 
(XHR, MediaStreaming, etc) or DOM specific scenarios - 
(createObjectURL()). The current W3C Streams API will focus on this 
aspect of the API surface, while leaving the core functionality to be 
defined in the base spec.

Once we've reorganized the components as defined above, we will share 
out further details for locations of the specs as well as solicit review.


Received on Friday, 7 February 2014 13:01:28 UTC