Contact emails
ri...@chromium.org, tyos...@chromium.org, dom...@chromium.org
Spec
https://streams.spec.whatwg.org/#ws
TAG review: https://github.com/w3ctag/spec-reviews/issues/163
Summary
WritableStream is the writable counterpart to ReadableStream (which shipped in 2015). It provides a standard abstraction for writing streaming data to a sink, with backpressure and queuing. Sinks can be either built-in or implemented in JavaScript.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/f1zzIHtRomQ/foZ6f5dKBwAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Interoperability Risk
Low.
Writable streams, and streams in general, have been the result of an active multi-vendor collaboration, guided the entire way by a large set of web-platform-tests which are co-developed with the specification and with other vendors. "Code coverage" of the writable streams portion of the spec currently stands at 96.63%. Readable streams have paved the way here with excellent interoperability, being deployed in Edge, WebKit, and Blink with compatible semantics, with Gecko following close behind.
Edge: has partially shipped readable streams and has expressed general support for writable streams
Firefox: In development and actively collaborating on the spec repo; their main implementer has already prototyped writable streams, although I don't know if he committed that code anywhere yet
Safari: In development. An earlier version of the spec ships in Safari Tech Preview (but not stable Safari); we are in contact with them about updating.
Web developers: Positive
Compatibility Risk
Low.
The WritableStream standard has stabilized. There has been a lot of activity with new tests being written and small adjustments since the Intent to Implement, as we work to nail down edge cases. None of these have made breaking changes to the API, and in general the changes have only been about edge case behaviors such as what happens when you close and then immediately abort the stream. At this point we are happy even with all the edge case behaviors.
You can view the issues being tracked in the spec repository. At this time all of the remaining issues are around future features (tagged "V2").
OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=658144
Entry on the feature dashboard
Safari: In development. An earlier version of the spec ships in Safari Tech Preview (but not stable Safari); we are in contact with them about updating.
LGTM1On Thu, Mar 30, 2017 at 11:26 PM Adam Rice <ri...@chromium.org> wrote:Safari: In development. An earlier version of the spec ships in Safari Tech Preview (but not stable Safari); we are in contact with them about updating.Update: they just shipped it in 10.1. It is interoperable for creating WritableStreams: the sink API is the same. pipeTo() from a ReadableStream to a WritableStream is also interoperable. The API for writing directly to a WritableStream has changed significantly; for the time being pipeTo() is the best choice for writing to a WritableStream to work cross-browser. I have written non-trivial code in Chrome that worked with Safari's implementation with no changes.On 31 March 2017 at 14:50, Domenic Denicola <dom...@chromium.org> wrote:Contact emails
ri...@chromium.org, tyos...@chromium.org, dom...@chromium.org
Spec
https://streams.spec.whatwg.org/#ws
TAG review: https://github.com/w3ctag/spec-reviews/issues/163
Summary
WritableStream is the writable counterpart to ReadableStream (which shipped in 2015). It provides a standard abstraction for writing streaming data to a sink, with backpressure and queuing. Sinks can be either built-in or implemented in JavaScript.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/f1zzIHtRomQ/foZ6f5dKBwAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Interoperability Risk
Low.
Writable streams, and streams in general, have been the result of an active multi-vendor collaboration, guided the entire way by a large set of web-platform-tests which are co-developed with the specification and with other vendors. "Code coverage" of the writable streams portion of the spec currently stands at 96.63%.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
LGTM2Thanks for the excellent WPT test suite!
Writable streams, and streams in general, have been the result of an active multi-vendor collaboration, guided the entire way by a large set of web-platform-tests which are co-developed with the specification and with other vendors. "Code coverage" of the writable streams portion of the spec currently stands at 96.63%.
Whoa, how did you get that! Is the technique applicable only to V8 extras or also C++ code?
What about the other implementations? Is there a page that shows passing percentages for all of the experimental implementations?
This is not a good sign... That means that the implementation will ship while already non-interoperable.
This is not a good sign... That means that the implementation will ship while already non-interoperable.
Blink is more interoperable with Safari with WritableStream available than it is without it. I am glad Safari shipped it, even though it's an older version which will cause some developer pain. Because it will also cause some developer joy when they can benefit from these new features.Philosophically speaking, I think a Living Standard implies that browsers being out of sync is going to be more common than not. That's the price we pay for a web platform that actually gets better with time.
☆PhistucK
☆PhistucK
☆PhistucK
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
☆PhistucK
☆PhistucK
☆PhistucK
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
☆PhistucK
☆PhistucK
☆PhistucK
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
☆PhistucK
☆PhistucK
☆PhistucK
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
With close() and write() on different objects, I guess that means that people will have to write different code for this to work with both WebKit's implementation and what is now in Blink?
☆PhistucK
☆PhistucK
☆PhistucK
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
With close() and write() on different objects, I guess that means that people will have to write different code for this to work with both WebKit's implementation and what is now in Blink?I'd rather people use pipeTo(), since it doesn't require hacks to achieve interoperability, but in the common case where you only use one writer you can paper over the difference by replacing the usualconst writer = writableStream.getWriter();withconst writer = writableStream.getWriter ? writableStream.getWriter() : writableStream;
Just don't put my name on it.
Might it be possible to set WritableStream.prototype.getWriter to something that makes the difference invisible?
☆PhistucK
☆PhistucK
☆PhistucK
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.