On 8 Nov 2016, at 21:07, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Nov 8, 2016, at 2:17 AM, Cory Benfield <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>> wrote:
Tubes is unquestionably a better API for this, but suffers from a lack of accessibility.
What is "accessibility" in this context?
“accessibility” in this context is essentially the collection of things that make it easy for users to a) identify a need for tubes, b) work out how to plug tubes into their application, and c) have a sensible evolution to handle evolving backpressure needs into tubes. Mostly this is a documentation thing, but there’s also a chicken-and-egg problem here, specifically: tubes provides a high-level API for flow control but requires that pre-existing code use a low-level one. How do we get from there to somewhere we can actually tell people “yeah, go use tubes”? On top of that we have: how do we justify using tubes when so much of for example Twisted’s codebase does not implement IPushProducer/IConsumer? How do people migrate a pre-existing codebase to something like tubes? How do people extend tubes to do something other than *propagate* backpressure (e.g. to implement a fast-fail path to error out rather than stop reading from a socket). All of these questions *have* answers, but those answers aren’t easily accessible. Part of this is an ongoing cultural problem which is that people who build small or non-distributed applications often don’t have to think about backpressure, so there’s another problem that also needs addressing: it needs to be so easy for people to extend their async producers and consumers of data to propagate and respond to backpressure appropriately that there’s no good reason *not* to do it. All of this complex mess of things is what I mean by “accessibility”. It needs to be easier to do the right thing than the wrong thing. Cory