<html><body>On 04:13 pm, markus@bluegap.ch wrote:<br /><br />&gt;I have yet another question... &#160;a producer has to learn about it's consumer <br />&gt;somehow, otherwise it would not know where to write it's data to.<br /><br />&gt;Why is that? What's the best way to associate a producer with a consumer? Is <br />&gt;something like the following okay:<br /><br />This is a really deep problem, unfortunately, and Valentino has correctly identified that it's the same one I was going to talk about when responding to his twisted-web posting :).<br /><br />Your solution doesn't really solve anything, since neither producers nor consumers are documented to have the attributes you are assigning, nor do anything with them.<br /><br />Consumers are documented to have a "write" method, but the documentation is misleading. &#160;The most common type of producer - tcp.Connection - does not put data into its consumer's "write" method, it calls its protocol's dataReceived method. &#160;Many other producers are actually written specifically to call higher-level methods on something other than their consumer (such as callRemote) rather than "write".<br /><br />The basic use-case here is that the responsibility for producing bytes and the responsibility for throttling data production are usually separated in an application. &#160;I agree that this is not really the best way to separate them. &#160;The API grew up almost by accident, it wasn't really designed intentionally, although it has worked surprisingly well considering.<br /><br />In many cases it does seem that we want a high-level API for setting up pipelines of producer-to-consumer-to-producer, or (in the case of web2 streams) end-to-end producer-producer-producer sequences. &#160;While many of these use-cases are superficially similar, my own attempts to resolve this shows that there is a surprising diversity of requirements which are difficult to resolve simultaneously by "simply fixing" the existing consumer / producer mess.<br /><br />Keep in mind, also, that a great deal of code has been written (and will be written before everyone has upgraded to the next version of Twisted) that uses the current IConsumer/IProducer APIs, and all of that will need to keep working for the forseeable future.<br /><br />You can find some discussion, as well as our attempts to create something better, here:<br /><br />&#160; &#160; http://twistedmatrix.com/trac/ticket/1956<br /><br />If you have new information, feel free to comment there, but please read all the comments and try to understand them first: there has been a *lot* of back-and-forth over this issue.</body></html>