| 13:39 | <lgrahl> | Hey folks o/ |
| 13:39 | <lgrahl> | Anyone up for a couple of Streams questions? |
| 13:58 | <lgrahl> | Ping, err... Domenic |
| 14:42 | <miketaylr> | (lgrahl: generally it's good to ask the questions, then people can answer them async, when they're around) |
| 14:43 | <lgrahl> | Ok, then I'll dump my questions |
| 14:43 | <annevk> | tobie: heya, if you happen to be around, do you know if there's an issue logged about the HTML diff tool failing? |
| 14:44 | <Domenic> | https://github.com/tobie/pr-preview/issues/51 |
| 14:44 | <annevk> | ah! |
| 14:44 | <lgrahl> | All APIs that I've seen are providing ReadableStream/WritableStream instances do not allow to provide a custom strategy. And I've also seen that WebSocketStream for instance uses a strategy with a desiredSize of 1. |
| 14:44 | <lgrahl> | Since TransformStreams allow to add additional buffering, is it good practice to have as little buffering as possible when exposing a raw transport stream? |
| 14:46 | <lgrahl> | Follow-up question: A TransformStream can safely use the default strategy where the desiredSize is 1 to avoid additional buffering, correct? But this still adds one additional chunk to the total pipeline buffer per additional TransformStream, or not? |
| 15:01 | <tobie> | annevk, Domenic: sorry I missed that issue, though I've been seeing the errors come in. |
| 15:02 | <Domenic> | lgrahl: these questions are too much for my early morning brain. You might be best off filing them on whatwg/streams. I bet ricea knows the answers off the top of his head, when he's awake. |
| 15:09 | <lgrahl> | Domenic: Any chance he'll read it later? :) |
| 15:09 | <Domenic> | I don't think he hangs out in this channel. |
| 15:12 | <lgrahl> | Ok, thanks. |
| 15:52 | <tobie> | Domenic, annevk: this seems to be related to a recent W3C update to TLS 1.3 that Heroku doesn't support. As noted in the issue (https://github.com/tobie/pr-preview/issues/51), I'm out of my depth and unsure how to move forward. |
| 15:52 | <Domenic> | :( thanks for looking in to it... |
| 15:52 | <Domenic> | It's surprising that curl doesn't support TLS 1.3 either |
| 15:56 | <tobie> | Domenic: Yves Lafont is looking into it on the W3C side. |
| 15:56 | <Domenic> | \o/ |
| 15:56 | <Domenic> | Ohhh, I am slightly less confused now, the deprecated versions of TLS are 1.0 and 1.1. |
| 15:57 | <Domenic> | So using TLS 1.3 is being cutting edge, not just non-deprecated. |
| 15:57 | <tobie> | yes |
| 15:57 | <Domenic> | Now it makes more sense why things would break. |
| 16:08 | <tobie> | Alright, annevk, others, this is now fixed (thanks to ylafon) |
| 19:34 | <lgrahl> | Domenic: Perhaps a more simple... well, a question: I'm still confused by the multitude of ways to cancel/close/error a source/sink and I'm very much lost on when to use what. I can controller.close and controller.error a source but I can only controller.error a sink. Why is that? |
| 19:35 | <Domenic> | lgrahl: the user of the writable stream sends the close signal. |
| 19:36 | <Domenic> | Whereas the creator of the readable stream sends the close signal. |
| 19:38 | <lgrahl> | I'm not sure I understand, yet. Consider wrapping a WebSocket. I get a close event. What do I need to do? Should I error the sink (and why)? Should I close the source (probably)? |
| 19:39 | <lgrahl> | Should I error the source if event.wasClean is false? |
| 19:44 | <lgrahl> | And should I error the sink if event.wasClean is false? I mean I've read through the spec but I still don't really understand what parts of the close signal of a bidirectional transport need to go where after having split it into a readable and writable side. |
| 19:47 | <lgrahl> | (Btw. this seems like a common issue for stream APIs. Python's asyncio also makes cancellation complicated when having split a transport into a StreamReader and StreamWriter. Unfortunately, I don't have a good solution other than good docs with good practices.) |
| 19:51 | <lgrahl> | Domenic: ^ |
| 19:52 | <Domenic> | lgrahl: the close event comes from the server? Then yes, that's an error. You can no longer write, even though the user of the writable stream did not call writer.close(). |
| 19:52 | <Domenic> | https://streams.spec.whatwg.org/#example-both |
| 19:53 | <Domenic> | (Hmm, that example seem to overwrite onclose a few times, probably should be using addEventListener.) |
| 19:54 | <lgrahl> | Yeah, I noticed that, too. Sorry for not having filed an issue. :) |
| 19:55 | <lgrahl> | The thing is that I don't really see that this needs to be an error. Why can't the server close the connection intentionally? If the writer doesn't have any queued writes, this should not be an issue. |
| 19:57 | <lgrahl> | Domenic: Okay, so, maybe I'll try to point to different things in the example instead: For the source, shouldn't it also check for event.wasClean and controller.error if it's false? |
| 19:58 | <Domenic> | It is always an error in the streams contract when you can no longer write despite never having called .close() |
| 20:00 | <lgrahl> | Hrm, I guess that makes sense. |
| 20:02 | <lgrahl> | Domenic: In WebSocketSource, should `this._ws.onclose = () => controller.close();` not be `this._ws.onclose = (event) => { if (event.wasClean) { controller.close() } else { controller.error(...) } };`? |
| 20:07 | <lgrahl> | In WebSocketSink, I don't understand why onclose is being rebound to null if the error event fired. |
| 20:08 | <lgrahl> | And then, finally, in WebSocketSink's abort method, should it really wait until closed? |
| 20:11 | <Domenic> | lgrahl: I really have a hard time doing these sorts of evaluations synchronously while also doing my other work. I hope you can take these questions to the issue tracker to allow myself and others to better process them. |
| 20:13 | <lgrahl> | Domenic: Will do. Sorry - I know how hard it can be to get into a flow. :) |
| 20:13 | <Domenic> | :) |
| 20:59 | <annevk> | tobie: thanks so much! |