"Tubes": Create a composable, flow-control and back-pressure friendly way to arrange parsing, processing, and emitting data
|Reported by:||jknight||Owned by:||Glyph|
|Cc:||Glyph, Jean-Paul Calderone, itamarst, radix, jknight, oubiwann, ashfall, ralphm, Tobias Oberstein, Julian Berman, free, daf||Branch:||
branch-diff, diff-cov, branch-cov, buildbot
Description (last modified by )
The current producer/consumer API has a couple of problems:
- 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.
streamingflag 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.
- It's awkward to chain producers and consumers with each other (XXX: this problem needs better documentation, use case, example of awkward code).
- 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.
We should design an API which does not have these problems.
Change History (57)
comment:20 Changed 11 years ago by
|Owner:||changed from Glyph to Jean-Paul Calderone|
|Priority:||low → normal|
comment:35 Changed 5 years ago by
|Author:||glyph → ashfall, glyph|
|Branch:||branches/tubes-1956 → branches/tubes-1956-2|
comment:40 Changed 4 years ago by
|Summary:||Make a less sucky producer/consumer API → "Tubes": Create a composable, flow-control and back-pressure friendly way to arrange parsing, processing, and emitting data|
Note: See TracTickets for help on using tickets.