<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div><div>Some thoughts while hacking:<br></div><div><br></div>- The argument having access to the responder locator and then eventually it going to a responder function is kind of useless, usually. The responder function already has a reference to the locator, usually called "self" :)<br>

</div>- The locator object can be shared between different connections, so a hack using the current status quo where you get the proto using the responder locator is... well, hacky.<br><br></div><div>Also, I do really really want the protocol and not the transport. This is because I want to pass a reference to the protocol around so that later I can call callRemote on it. That I can also get the transport is mostly just gravy so that I can return nice things for my fake transport's getHost/getPeer.<br>

</div><div><br></div>So, to reiterate:<br><br></div>- I think all the docstrings should reflect the real situation. I guess I need to file a ticket for that.<br></div>- Maybe there should be a new API that passes the proto (and actually means "proto" ;))<br>

<br></div><div>I think I have some code up (or will have some code up soon, depending on when you read this email) that does have sort-of working multiplexed transports:<br><br><a href="https://github.com/lvh/txampext">https://github.com/lvh/txampext</a><br>

<br></div><div>When done, this will be available from pypi as txampext==0.0.6.<br></div><div><br></div><div>If anyone is interested in this, the next big feature mark will be integrating _habnabit's AMP producer stuff, so that it's not just transports, but IConsumer/IProducer transports as well.<br>

</div><div><br></div>cheers<br>lvh<br></div>