*deep necromantic thread magic*

On Thu, Oct 3, 2013 at 11:54 AM, Glyph <glyph@twistedmatrix.com> wrote:
If I can change "proto" to mean "actually the protocol not something else" then that seems plenty easy to add, and it would definitely be cool if people don't have to mess with this nonsense themselves for something as ostensibly simple as having access to the protocol :-)

Keep in mind that in the authentication case I mentioned, your post-auth object may well subclass AMP and therefore "actually" be a protocol; but it still won't have a transport.  What do you propose happen in that case?

Isn't the post-auth object a box receiver? I mean, yes, it can be a box receiver by virtue of subclassing AMP and therefore *secretly* being a proto. I'd be totally fine (for my use case) to just have the transport available somewhere :) (The transport that the AMP bytes are being sent over; so not, say, a TCP transport underlying a TLS connection or something.)

For fixing this (I'll file tickets if you confirm):

- ResponderLocator's behavior is pretty much just broken. It's using Command.makeResponse. That says it wants an AMP. It's clearly just getting a responder locator. However, it seems like the problem here is makeResponse's crappy interface. It shouldn't want an AMP. So, we should fix makeResponse's docstring, and all of the other cases where t.p.amp asks for an AMP and shouldn't.
- The proto argument name is stupid. Can we fix it?
- There should be a new method on IArgumentType, parallel to fromBox (but not toBox?), that gets a reference to the transport passed to it. If so: where does it get that?

Does that sound about right?