On 03/02/2013 12:19 PM, Glyph wrote: > I wrote a blog post some time ago explaining why you want static > declarations, even if your programming language is all nice and dynamic:
Being able to "early drop" bad PDUs is a fine notion, but it's not a property that comes with zero cost. If you feel that the cost/benefit tradeoff is not useful in your case (and I do) then it doesn't make sense to pay it. AMP would be somewhat more attractive (to me) if it were possible to run with the IDL just on the "server" (i.e. callee); this would achieve the goal of protocol-level sanity checking, without the cost of having to distribute the IDL to the clients. Presumably it would be possible to implement this now - have an AMP discovery command that dynamically builds the client-side IDLs. But there's no incentive for me to do that. For the use-cases I have, the protocol version/interop problem is not relevant. > not full replacements for AMP because they're asymmetrical and don't > support pipelining. With AMP, a client can receive requests from a > server, you don't need to have a TCP handshake for every request, you You don't need to do a TCP handshake for every request in any of those protocols either. Long-lived TCP/HTTP sessions are quite common, though not universal. It will be interesting to see if and how HTTP/2.0 solves a lot of these issues. > can receive responses out of order, and you can receive a request while > waiting for a response, and so on. Obviously. But I would tend to use those protocols when either those properties are not needed (perhaps even undesireable) and may be impossible to make use of (if the far end is a synchronous, blocking client unable to make use of out-of-order responses or server-initiated messages). In those cases, it would also be rare for AMP to be available, and it certainly wouldn't be pre-installed. "Install this Java library on your Oracle servers then..." "Ha ha no go away." You seemed curious why someone wouldn't use AMP. Personally I have two common use-cases: 1. Communicating between two trusted Twisted processes, for which PB is good enough. 2. Communicating with a semi-trusted third party process, for which a RESTful interface or XML/JSON RPCs are *available* and sufficiently secure and capable for my needs. Obviously other people will have radically different needs, but for me, AMP adds little. Cheers, Phil _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
