[Twisted-Python] AMP Argument.toBox's proto argument is a locator, not the proto?

[Laurens Van Houtven]

*deep necromantic thread magic*

On Thu, Oct 3, 2013 at 11:54 AM, Glyph <glyph at 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?

cheers
lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20131120/6f4c58cd/attachment.html>