It is great to see Project Bedrock moving forward in #1446 :)
One thing that I am noticing is that ConnectionContext is the connection object on the server while IConnection is the connection object on the client. And they both use IDuplexPipe as the underlying "bytes-passing" object.
This means that we can write libraries that only depend on IDuplexPipe to send and receive stuff, which is nice.
However, we can't do the same for connections:
For example, in a server-to-server scenario (and more generally, peer-to-peer), any device can initiate a connection to another device. And ideally, a device would want to manage all connections (both those that it initiated and those that where initiated to it) together.
So, let's say A connects to B, B connects to C and C connects to A. (So, we get a mesh network.)
How do we write a library that allows A to broadcast messages to B and C?
Another way to think about it is: Once a connection comes out of the "factory", it shouldn't matter how it came to be.
It is great to see Project Bedrock moving forward in #1446 :)
One thing that I am noticing is that
ConnectionContextis the connection object on the server whileIConnectionis the connection object on the client. And they both useIDuplexPipeas the underlying "bytes-passing" object.This means that we can write libraries that only depend on
IDuplexPipeto send and receive stuff, which is nice.However, we can't do the same for connections:
For example, in a server-to-server scenario (and more generally, peer-to-peer), any device can initiate a connection to another device. And ideally, a device would want to manage all connections (both those that it initiated and those that where initiated to it) together.
So, let's say A connects to B, B connects to C and C connects to A. (So, we get a mesh network.)
How do we write a library that allows A to broadcast messages to B and C?
Another way to think about it is: Once a connection comes out of the "factory", it shouldn't matter how it came to be.