On Oct 1, 2013, at 1:13 AM, Laurens Van Houtven <email@example.com> wrote:
The problem here is that you can do AMP decoding without a protocol anywhere in sight. A CommandLocator by itself, passed appropriate boxes to the callables returned by locateResponder, is capable of speaking AMP just fine, as long as you don't care about speaking it to an actual byte stream :-). (And ostensibly this is one way to speak AMP over transports other than BinaryBoxProtocol.)
In the case of AMP routes (something it would be very nice to integrate into the main protocol), you have multiple command locators per transport, and each one might have its own properties that would be interesting to Argument types,
This is why putting requirements on the thing-doing-the-parsing in the Argument definition makes sense; the Command could interrogate its prospective Responder class, asking each of its Argument objects if it will be able to satisfy their requirements in turn, at the time that CommandLocator.__metaclass__.__new__ gets invoked, rather than once your protocol is already trying to respond to commands.
I believe it currently means "responderLocator". _wrapWithSerialization is where the magic happens if you want to confirm.
It's probably too late for this method, but you can always add a new one :-)
The hand-rolled CR/OTP crap is really not supposed to be the interesting part. Really, that should just be SASL. The interesting part is the integration with cred.
(Augh, and we didn't know the difference between a one-time password and a one-time pad, and the wrong word is right there in the wire format... Augh augh augh)
Notice that in that authentication code, CredReceiver *sets self.boxReceiver* to the result of portal.login. It hands off processing of the parsed AMP boxes to another IBoxReceiver. So the thing parsing the commands - the post-authentication protocol - is what the Arguments will currently have direct access to (as that will be the CommandLocator as well) but that object will have no transport; only a boxSender.
You could add a new interface where it's "fixed", but given the case I just described above, what does "fixed" mean?
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?