| 11:51 | <iwan.aucamp> | Is there a list of implementations of https://url.spec.whatwg.org/ somewhere? Specifically looking for a python implementation. |
| 11:51 | <iwan.aucamp> | But would settle for library in any other language also |
| 11:52 | <iwan.aucamp> | Ah nvm, I found some |
| 11:54 | <annevk> | Mattias Buelens: how does transformAlgorithm convey stream closure or an error of some kind? |
| 11:55 | <annevk> | In a TransformStream that is; from the surface it seems like it only deals with successful scenarios |
| 11:56 | <Luca Casonato> | annevk: yes this is an issue. There is an open issue on the spec for this that one of our engineers was going to look into. Let me find it |
| 11:56 | <Mattias Buelens> | annevk: yes this is an issue. There is an open issue on the spec for this that one of our engineers was going to look into. Let me find it |
| 11:57 | <Luca Casonato> | crowlkats has started work on that. Don't know what the current progress is though |
| 12:54 | <annevk> | Thanks! Since this is mainly about specification language I guess I can figure something out whereby I either wait for sufficient chunks or the stream to close or error. The error does propagate at the moment, right? Or does everything in Fetch that uses TransformStream have some kind of bug? |
| 13:11 | <Luca Casonato> | Thanks! Since this is mainly about specification language I guess I can figure something out whereby I either wait for sufficient chunks or the stream to close or error. The error does propagate at the moment, right? Or does everything in Fetch that uses TransformStream have some kind of bug? TransformStream is just completely oblivious to the error right now. |
| 13:12 | <Luca Casonato> | But if you error a readable stream that is piped through a transform stream into a writable stream, the writable stream will be aborted correctly. |
| 13:19 | <annevk> | Thanks Luca, I guess I'll add a comment for now |
| 13:40 | <annevk> | Mattias Buelens: Luca Casonato: here's a draft, would love your critique: https://gist.github.com/annevk/ca5475aa173820effdd90b5298bf49c1 |
| 13:42 | <annevk> | (the "in parallel" has a JS engine running concern is known btw, I'm not really sure how to solve that other than having "concept" streams, which I guess we should get to to solve a number of such issues) |
| 13:45 | <Mattias Buelens> | What if the response body is shorter than 1024 bytes? You'd wait forever in step 3, right? |
| 13:47 | <Mattias Buelens> | You probably want a flushAlgorithm, so you can stop waiting if you reach EOF before filling up 1024 bytes. |
| 13:48 | <evilpie> | Sort of related: In Firefox we also have non-standard error callback from UnderlyingSource, because that was required for something in fetch |
| 13:51 | <annevk> | Interesting, that's probably worth raising in an issue somewhere evilpie |
| 15:14 | <Doug Conmy> | annevk: Just checking in. Were you able to get in touch with your Mozilla contacts? I'll watch on the PR. |
| 15:52 | <annevk> | Hey Doug Conmy, yeah, Tantek will update standards-positions. TL;DR will be that we end up not being supportive due to the underlying protocol not being a standard as I understand it. Sorry that it took so long, I've been kinda swamped. |
| 20:22 | <Domenic> | Noam Rosenthal: you may have forgotten to push for https://github.com/whatwg/html/pull/7866? |
| 21:35 | <Noam Rosenthal> | Noam Rosenthal: you may have forgotten to push for https://github.com/whatwg/html/pull/7866? |
| 21:36 | <Noam Rosenthal> | done |
| 21:40 | <Noam Rosenthal> | Domenic: I tried to find something a bit more rigorous for the CORS-attribute keyword thingy, if you want to revise it a bit or use your previous less-rigorous text feel free. |