Add support for using read-only streams with AWS APIs

[itspolly]

Describe the feature

I'd like support for using read-only streams with AWS APIs.

Use Case

ByteStream in Smithy has a stream enumeration case with an associated value of type Stream. I have an object that conforms to ReadableStream which I want to upload to S3, which I cannot currently do without conforming my ReadableStream-conforming object to WriteableStream.

Proposed Solution

I've outlined a few options:

• Refactor the ByteStream.stream enumeration case's associated value's type to be of ReadableStream instead of Stream and rename ByteStream to ReadableByteStream
• Add a new enumeration case to ByteStream, readableStream
• Add a new type, ReadableByteStream, which has similar enumeration cases to ByteStream, but stores a ReadableStream as the associated value of the stream case

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

[jbelkins]

Hi @itspolly,

As you have noted, the ByteStream type does require in its .stream() case that the associated stream conform to both ReadableStream and WriteableStream. I think this was originally done for simplicity, so that the same ByteStream type could be used for both requests and responses. And all of the SDK's public stream types (FileStream, BufferedStream) provide both functions. But as you have noted, you have to conform your stream to both the read & write protocols when you only want to read from it.

The suggestions you make would all solve the immediate problem, but we cannot make such changes until a new SDK major version is published, because each would break compile for existing code.

What I would suggest you do, until we can update our stream interfaces to require a more specific stream type, is to implement the WritableStream interface on your readable stream with no-op implementations of the WritableStream methods. (We can confirm that a stream provided as a request body doesn't get accessed as a WritableStream by the SDK so nothing bad will happen in this specific use pattern. Also, if possible, make your readable stream seekable because it helps with the SDK's automatic retry feature.)

I recognize that this is not optimal since it requires that you add useless "boilerplate" code and it allows your non-writable WritableStream to be used in places where it won't actually work, but it will allow your stream to be safely used as a request body today, without SDK updates.

Please let us know if you have any further questions.