| 07:19 | <annevk> | Luca Casonato: that looks pretty great; one thing that can help with things like this is a comparison with other programming languages; also curious if we need streaming (guess not, but might be worth calling out in a FAQ or some such) |
| 07:40 | <Luca Casonato> | annevk Thanks for the feedback! I'll add an FAQ, and a section on other languages' implementations. There is a comment about streaming in the doc - I think the best way to implement streaming would be a seperate BinaryEncoderStream / BinaryDecoderStream akin to the text encoders. |
| 07:42 | <Luca Casonato> | But maybe a synchronous capable streaming API would make sense too? That could be added via a stream: true in an options bag to encode / decode / decodeInto. |
| 07:42 | <Luca Casonato> | Anyway - will put tjhese comments into an issue and link to it from the FAQ. |
| 09:30 | <Luca Casonato> | annevk FAQ and language/environment comparison added. |
| 12:08 | <annevk> | Luca Casonato: I'd also ask MattiasBuelens and ricea for review |
| 16:26 | <tabatkins> | fwiw, isn't base64-encode still bytes -> bytes? The output bytes are chosen to be displayable as ASCII, but it's not "text"; there's no codepoints involved. |
| 16:26 | <tabatkins> | (You wouldn't then encode base64 "text" as utf-16, for example.) |
| 16:38 | <jgraham> | That seems technically true, but the usual use case for base64 is where you need a Text type (e.g. for JSON). So thinking of it as a bytes -> Text transformation fits the use cases better |
| 16:40 | <jgraham> | (and if the whole payload including the base64 part was then going to be encoded as UTF-16 that's what you'd do, not embed the base64 bytes directly in a UTF-16 message) |