| 1 | | The current one is annoying in a bunch of ways. Design one that isn't. |
| | 1 | The current producer/consumer API has a couple of problems: |
| | 2 | |
| | 3 | * It's impossible to get notifications of buffer size changes, which is important for certain kinds of timeout logic. For example, if you buffer a bunch of output, and then time out if the peer is inactive (isn't reading any data), then you need to know not just when the buffer is empty but when some data is consumed. |
| | 4 | * The {{{streaming}}} flag doesn't really make sense. It complicates the implementation of nested producers. While it doesn't actually break anything, it's just a bug. There's no reason to have it and it should be removed. |
| | 5 | * It's awkward to chain producers and consumers with each other (XXX: this problem needs better documentation, use case, example of awkward code). |
| | 6 | * IProtocol, ITransport, IProducer and IConsumer all have redundant "here's some data" / "there will be no more data" methods which are subtly different. These should be unified so that the protocol consuming data from the transport and the transport consuming data from the protocol look the same. |
| | 7 | |
| | 8 | We should design an API which does not have these problems. |
