On Nov 22, 2013, at 4:10 AM, Laurens Van Houtven <_...@lvh.io> wrote:
> 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.
Except that maybe your protocol is just a BinaryBoxProtocol, and has no
callRemote method. Or maybe it's actually HTTP and feeding things to AMP after
some deserialization pass, like via JSON (aren't you even doing this already in
some other code?). Is there even a "protocol" visible to this code in that
case?
If your contract is that you accept an IProtocol, then what you can do is
pretty much just call dataReceived and connectionLost ;-) unless you have some
other reason to believe it provides some other interfaces.
> So, to reiterate:
>
> - I think all the docstrings should reflect the real situation. I guess I
> need to file a ticket for that.
Well, that's definitely true.
> - Maybe there should be a new API that passes the proto (and actually means
> "proto" ;))
I still think that before providing this new mechanism we need *some* way of
declaring that we expect more from "the protocol".
> 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:
Cool.
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
