-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make FS and net APIs work well with WHATWG streams #13614
Comments
From a quick look, this seems like a good solution. I'd say that this is "blocked" on whatwg/streams#1145, and writable byte stream (there isnt a concrete issue about it, but such a concept is mentioned in various issues) |
I am not quite sure why the former would be needed. As for writable byte streams: how would they be different to regular write streams? There is no point in "bring your own buffer" for writers, as you always bring your own buffer there (you give the writable stream something to write). |
i agree for the former thats why "blocked" with quotes. regarding the latter: byte ≠ byob, there is a difference. |
Yup, this is what my current thinking was. I think adding support for these "byte" streams would be a backwards compatible change (or would it not?). |
Well, from my findings there is no spec suggestion, so i have no idea, but i assume its gonna be a similar deal to readablestream, so then yea, it would be backwards compatible |
Currently our FS and net APIs use "Go style" streams (
Reader
/Writer
). While these kinds of streams are very fast and simple, they are not very well compatible withfetch
and all our newfangledCompressionStream
andTextEncoderStream
utilities.Currently
std/streams
hasreadableStreamFromReader
andwritableStreamFromWriter
functions to convert fromWriter
toWritableStream
and fromReader
toReadableStream
. While these are convenient, they are not as convenient as not having to use them at all.To solve this I am proposing adding a
readable
andwritable
property to all of our internal implementations ofReader
andWriter
.readable
would return aReadableStream<Uint8Array>
andwritable
would return aWritableStream<Uint8Array>
.This makes
Deno.File
really convenient to use for use with the native HTTP server or fetch for example:This could land independently of how #11018. These two APIs can co-exist - it doesn't need to be one or the other.
The text was updated successfully, but these errors were encountered: