Re: publish WD of Streams API; deadline Nov 3
On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon as possible. Given how long we have been trying to figure out streams, waiting a little longer to see Domenic's proposal should be fine I think. No need to start rushing things through the process now. (Although on the flipside at some point we will need to start shipping something.) -- http://annevankesteren.nl/
Re: publish WD of Streams API; deadline Nov 3
OK. There seems to be some disconnect, but I'm fine with waiting for Domenic's proposal first. Takeshi On Thu, Oct 31, 2013 at 7:41 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon as possible. Given how long we have been trying to figure out streams, waiting a little longer to see Domenic's proposal should be fine I think. No need to start rushing things through the process now. (Although on the flipside at some point we will need to start shipping something.) -- http://annevankesteren.nl/
RE: publish WD of Streams API; deadline Nov 3
Agreed. Some of the points listed appear to be things already addressed. Takeshi and I have some feedback on the initial mail, but will wait and provide thoughts on the proposal instead. Looking forward to seeing it. From: tyosh...@google.com Date: Fri, 1 Nov 2013 12:18:47 +0900 To: ann...@annevk.nl CC: dome...@domenicdenicola.com; art.bars...@nokia.com; public-webapps@w3.org Subject: Re: publish WD of Streams API; deadline Nov 3 OK. There seems to be some disconnect, but I'm fine with waiting for Domenic's proposal first. Takeshi On Thu, Oct 31, 2013 at 7:41 PM, Anne van Kesteren ann...@annevk.nlmailto:ann...@annevk.nl wrote: On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon as possible. Given how long we have been trying to figure out streams, waiting a little longer to see Domenic's proposal should be fine I think. No need to start rushing things through the process now. (Although on the flipside at some point we will need to start shipping something.) -- http://annevankesteren.nl/
RE: publish WD of Streams API; deadline Nov 3
From: Arthur Barstow [mailto:art.bars...@nokia.com] If you have any comments or concerns about this proposal, please reply to this e-mail by November 3 at the latest. I have some concerns about this proposal, and do not think it is solving the problem at hand in an appropriate fashion. I believe it does not provide the appropriate primitives the web platform needs for a streams API. Most seriously, I think it has ignored the majority of lessons learned from existing JavaScript streaming APIs. Here are specific critiques, in ascending order of importance. - It has a read(n) interface, which is not valuable [1] but constraints the API in several awkward ways. - It assumes MIME types are at all relevant to a streaming data abstraction, when this is not at all the case. - In general, is far too backward-looking in attempting to integrate things like blobs or object URLs into what is supposed to be a forward-looking primitive for the future of the extensible web. Replacing these various disparate concepts is what developers want from streams [2]. - It conflates text streams and binary data. As outlined in previous messages [1], what type of data the stream contains *must* be an *immutable* property of the stream. In contrast, the proposed API actively encourage mixing multiple data types within a stream via readType, readEncoding, and the overloaded write method. - It conflates readable and writable streams, which prevents a whole class of abstractions and use cases like: read-only file streams; write-only HTTP requests; and duplex streams which read to one channel and write to another (e.g. a websocket, where writing pushes data to the server and reading reads data from the server---not the written data, but data that the server writes to you). Indeed, the only use case this proposal supports is transform streams, which take data in one end and output new data on the other end. - It provides no mechanism for backpressure signaling to readable stream data sources or from writable stream sinks. As we have heard previously, any stream API that does not treat backpressure as a primary issue is not a stream API at all. [3] - More generally, it does not operate at the correct level of abstraction, which should be close to the I/O primitives streams are meant to expose. This is evident in the general lack of APIs for handing interaction with and signaling to underlying I/O sources or sinks. - It's pipe mechanism is poorly thought out, and does not build on top of the existing primitives; indeed, it seems to install some kind of mutex lock that prevents the other primitives from being used until the pipe is complete. The primitives do not support multiple consumers, so the pipe mechanism handles that case in an ad-hoc way. It is not composable into chains in the fashion of traditional stream piping. Its lack of backpressure support prevents expression of key use cases such as piping a fast data connection (e.g. disk) to a slow data connection (e.g. push to a slow mobile device); piping a slow connection to a fast one; piping through encoders/compressers/decoders/decompressors; and so on. In general, it appears to take no inspiration from prior art, which is a shame since existing stream implementations all agree on how pipe should work. In light of these critiques, I feel that this API is not worth pursuing and should not proceed to Working Draft status. If we are to bring streaming data to the web platform, we should instead do it correctly, learning the lessons of the JavaScript stream APIs that came before us, and provide a powerful primitive that gives developers what they have asked for and serves as something we can layer the web's many streaming I/O interfaces on top of. I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon as possible. Thanks, -Domenic [1]: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0355.html [2]: http://imgur.com/a/9vFGa#11 [3]: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0275.html
Re: publish WD of Streams API; deadline Nov 3
As you mention streams are existing since the begining of times and it's incredible that this does not exist on a web platform, but apparently the subject is still not so easy, node changed its stream quite a lot of time. I probably will not be able to answer back in the coming days but your judgement is tough, this API is the concatenation of thoughts of the Overlap thread. Indeed it must clarify the writable/readable aspects, as well as the flow control/congestion, moreover than, despite of what you are saying, the API does support multiple consumers, and I/O, it's close to node streams. Of course you must conflate text and binary, you can not spend your time converting to text, to ArrayBuffer, to ArrayBufferView, to Blob, the user API knows what it is streaming. Regards, Aymeric Le 30/10/2013 19:04, Domenic Denicola a écrit : From: Arthur Barstow [mailto:art.bars...@nokia.com] If you have any comments or concerns about this proposal, please reply to this e-mail by November 3 at the latest. I have some concerns about this proposal, and do not think it is solving the problem at hand in an appropriate fashion. I believe it does not provide the appropriate primitives the web platform needs for a streams API. Most seriously, I think it has ignored the majority of lessons learned from existing JavaScript streaming APIs. Here are specific critiques, in ascending order of importance. - It has a read(n) interface, which is not valuable [1] but constraints the API in several awkward ways. - It assumes MIME types are at all relevant to a streaming data abstraction, when this is not at all the case. - In general, is far too backward-looking in attempting to integrate things like blobs or object URLs into what is supposed to be a forward-looking primitive for the future of the extensible web. Replacing these various disparate concepts is what developers want from streams [2]. - It conflates text streams and binary data. As outlined in previous messages [1], what type of data the stream contains *must* be an *immutable* property of the stream. In contrast, the proposed API actively encourage mixing multiple data types within a stream via readType, readEncoding, and the overloaded write method. - It conflates readable and writable streams, which prevents a whole class of abstractions and use cases like: read-only file streams; write-only HTTP requests; and duplex streams which read to one channel and write to another (e.g. a websocket, where writing pushes data to the server and reading reads data from the server---not the written data, but data that the server writes to you). Indeed, the only use case this proposal supports is transform streams, which take data in one end and output new data on the other end. - It provides no mechanism for backpressure signaling to readable stream data sources or from writable stream sinks. As we have heard previously, any stream API that does not treat backpressure as a primary issue is not a stream API at all. [3] - More generally, it does not operate at the correct level of abstraction, which should be close to the I/O primitives streams are meant to expose. This is evident in the general lack of APIs for handing interaction with and signaling to underlying I/O sources or sinks. - It's pipe mechanism is poorly thought out, and does not build on top of the existing primitives; indeed, it seems to install some kind of mutex lock that prevents the other primitives from being used until the pipe is complete. The primitives do not support multiple consumers, so the pipe mechanism handles that case in an ad-hoc way. It is not composable into chains in the fashion of traditional stream piping. Its lack of backpressure support prevents expression of key use cases such as piping a fast data connection (e.g. disk) to a slow data connection (e.g. push to a slow mobile device); piping a slow connection to a fast one; piping through encoders/compressers/decoders/decompressors; and so on. In general, it appears to take no inspiration from prior art, which is a shame since existing stream implementations all agree on how pipe should work. In light of these critiques, I feel that this API is not worth pursuing and should not proceed to Working Draft status. If we are to bring streaming data to the web platform, we should instead do it correctly, learning the lessons of the JavaScript stream APIs that came before us, and provide a powerful primitive that gives developers what they have asked for and serves as something we can layer the web's many streaming I/O interfaces on top of. I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon
