- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Sat, 10 Aug 2013 02:36:40 +0000
- To: Isaac Schlueter <i@izs.me>, Jonas Sicking <jonas@sicking.cc>
- CC: Austin William Wright <aaa@bzfx.net>, Takeshi Yoshino <tyoshino@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Isaac has essentially explained what I was getting at earlier, except much more clearly. When I said "this allows better pipelining and backpressure down to the network and file descriptor layer," I was essentially saying "implementing read or write operations as cancellable and incremental does not fit well with making them atomic operations that can fit into architecture of streams with flow-control." And, as Isaac again eloquently pointed out, streams without flow control are not streams at all. ("You're Missing the Point of Streams," anyone? :P)
Another way of looking at it, is that a streaming API is itself incremental and cancellable. It makes no sense to say that each read from or write to the stream is *also* incremental and cancellable; why introduce another layer of entirely-unnecessary depth before you reach the atomic level of non-incremental, non-cancellable reads/writes? What use case does that serve?
Received on Saturday, 10 August 2013 02:37:52 UTC