search

whatwg / streams

Streams Standard
https://streams.spec.whatwg.org/
Other
1.35k stars 160 forks source link

Should we add writableStream.write()? readableStream.read()? #1072

Open domenic opened 4 years ago

domenic commented 4 years ago

I was reviewing https://wicg.github.io/native-file-system/#api-filesystemwritablefilestream, which is one of the the major non-TransformStream users of WritableStream in spec land so far. And I noticed they added a write() convenience method that just wraps this.getWriter().write() + a release step, similar to the existing writableStream.close() and writableStream.abort().

It feels like maybe we're doing something wrong, if specs are subclassing us to add convenience methods in this way. Should we consider adding one-shot writing methods? What about one-shot reading methods?

It would be a nice simplification for folks who are just writing simple code and don't need to care about the exclusivity of their writers/readers...

On the other hand, maybe the real issue here is that it's too hard to add convenience methods to the return value of getWriter()? Maybe if that were easier, the NativeFS spec would have stuck with the "acquire a writer first" design, and just added the seek() and truncate() convenience methods to the writer?

/cc @mkruisselbrink

ricea commented 4 years ago

My impression is that the write() method is more focussed on providing features that are not available in in the WritableStreamDefaultWriter write() method, rather than convenience.

domenic commented 4 years ago

That was my initial impression, but it appears to not be the case: https://wicg.github.io/native-file-system/#dom-filesystemwritablefilestream-write .

mkruisselbrink commented 4 years ago

Heh, yeah. I think earlier on we had some thoughts that the via the WritableStreamDefaultWriter should only accept bytes, and we'd provide the Stream.write as a convenience to support blobs and strings as well. But then to get seek/truncate working the underlying sink would have to accept something more complicated anyway. So yeah, now it is just a wrapper around creating a writer.

domenic commented 4 years ago

An alternative would be to go the other way around, and have stream.write() only accept blobs/strings/bytes (and not accept "command" chunks, for which you should use stream.truncate() and stream.close().) But I'm not sure pushing in that direction would be sound; it feels more like I'm trying to justify the separation, versus actually making the API better.