Runtime: API Proposal - Stream to Pipe Wrapper

[Drawaes]

Rationale

Currently pipelines has no "endpoints" to speak of. There is a vast array of endpoints and "middleware" available in streams. In order to bridge the gap a class should be provided to wrap a stream and provide a pipe on top of it. This would provide access to the rich tapestry of streams to the new world of pipelines.

I believe that both myself @mgravell and aspnetcore have implemented these a number of times so it is worth this being a type provided by the BCL

API Shape

The following API is proposed.

namespace System.IO.Pipelines
{
    public class StreamPipe : IDuplexPipe, IDisposable
    {
        public StreamPipe(Stream stream, PipeOptions pipeOptions)
            : this(stream, pipeOptions, true) { }

        public StreamPipe(Stream stream, PipeOptions pipeOptions, bool ownsStream) { }

        public PipeReader Input => throw new NotImplementedException();
        public PipeWriter Output => throw new NotImplementedException();
        public void Dispose() => throw new NotImplementedException();
    }
}

Open questions

1. Should the stream be available as a property on the wrapper?
2. Should there be a read only write only version (single pipe not a duplex pipe?)

/cc @geoffkizer @stephentoub @mgravell @davidfowl @benaadams

Related dotnet/runtime#25087
Related dotnet/runtime#26668

[mgravell]

re your 2 - indeed, not all Streams are duplex. There's also read-only streams that can be meaningfully and gainfully exposed as a PipeReader, and write-only streams blah blah PipeWriter. Any API should be very clear which is being supported; "create a StreamPipe but only use the .Input is ugly.

for my pre-existing implementation, I ended up using factory methods: CreateReader, CreateWriter, CreateDuplex etc. I'm not saying it is perfect, but the reality is that Stream is hugely ambiguous. Even testing .CanRead / .CanWrite doesn't tell you whether it is duplex (see: FileStream, MemoryStream, etc).

happy to provide my implementation for examples/discussion, but actively not linking to it yet to not poison the well

[Drawaes]

I would be happy with a StreamPipeWriter and StreamPipeReader and have this as well but I think they could be separate unless there is a drive for both in one review. This should throw if the pipe isn't writable and readable in my opinion.

[benaadams]

re your 2 - indeed, not all Streams are duplex.

https://github.com/dotnet/corefx/issues/27268 "Add IPipeReader and IPipeWriter and have IDuplexPipe inherit from them" 😢

[mgravell]

@benaadams I'm just going to point out the other missed opportunity here... IDuplexPipe : IDisposable. It probably should have been. But that ship has sailed, so...

[Drawaes]

In saying all that..... There aren't any endpoints so maybe it's a blessing rather than a curse?

[mgravell]

In support of why we need at least a Stream wrapper, please see Pipe Dreams, part 2 - note part 1 is also relevant as a discussion of the problems that plague the Stream API, as further support for the "pipelines > stream" camp :)

[davidfowl]

Dupe of https://github.com/dotnet/corefx/issues/27246