Re: Update on Streams API Status

2014-02-10 Thread Aymeric Vitte


Le 07/02/2014 10:52, Anne van Kesteren a écrit :

As for createObjectURL(), it has not been a great success for Blob
objects. I'm not really sure we should widen that experiment. At least
not until the way they are supposed to be implemented for Blob objects
has actually been done in practice.


Do you mean that browsers are not implementing correctly createObjectURL 
right now?


Regards

Aymeric

--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms




Re: Update on Streams API Status

2014-02-08 Thread Arthur Barstow

On 2/6/14 11:31 PM, ext Feras Moussa wrote:

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:


This looks real good to me so thanks Feras, Takeshi, Domenic and others 
that helped with this!



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.


Looking forward to that.

-AB





Re: Update on Streams API Status

2014-02-07 Thread Anne van Kesteren
On Fri, Feb 7, 2014 at 5:31 AM, Feras Moussa feras.mou...@hotmail.com wrote:
 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.

Sounds great, thanks guys!

As for createObjectURL(), it has not been a great success for Blob
objects. I'm not really sure we should widen that experiment. At least
not until the way they are supposed to be implemented for Blob objects
has actually been done in practice.


-- 
http://annevankesteren.nl/



Update on Streams API Status

2014-02-06 Thread Feras Moussa
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.
 
Thanks,
Feras