On Mar 2, 2013, at 3:25 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:

On 03/01/2013 10:27 PM, Glyph wrote:

 What is AMP too much of?  Memory?  CPU?  Bandwidth?  API complexity?
 Code size?  As compared to what?

FWIW, every time (all three of them...) I've looked at AMP I got rapidly 
bored and ended up using PB. My use-cases have usually been 
Twisted->Twisted, and the AMP "Command" definition, and syncing said 
defs up at both ends, was hassle I didn't need.

When I need to talk to external systems I almost always use some REST, 
XMLRPC or JSON-RPC interface, because they're usually available 
out-of-the-box.

I also don't care for the idea of statically typing the command defs; 
I'm sure this helps when talking to languages with crappy typing 
systems, but honestly - who uses Java these days? ;o)

I wrote a blog post some time ago explaining why you want static declarations, even if your programming language is all nice and dynamic:

<http://glyph.twistedmatrix.com/2008/07/static-on-wire.html>

Even if all you care about is Twisted->Twisted, there are potential resource exhaustion and implementation-confusion attacks against PB that are very hard to mitigate in its current form.  That said, for the sorts of places where PB is useful (communicating about and synchronizing arbitrarily deep and complex object graphs), you're probably going to have those exhaustion attacks anyway and using something like AMP would just be more typing.  So as long as you're version-synchronized and at least partially trusted on both ends of the wire, PB is a fine choice as well.

"REST" (by which you mean "HTTP", I'm sure), XMLRPC, and JSON-RPC are 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 can receive responses out of order, and you can receive a request while waiting for a response, and so on.

-glyph