[Twisted-Python] Jellying Decimals?

glyph at divmod.com glyph at divmod.com
Tue Oct 9 20:21:49 EDT 2007


On 9 Oct, 11:55 pm, jasper at peak.org wrote:
>I understand that PB is still maintained, but it's also a dead end 
>without further development, and rather lacking in a few areas.  From 
>the bits I've seen Foolscap looks like it'll be enough of an 
>improvement that I'll happily switch when it's done.  I'd actually 
>switch now, but I need something stable for the time being.

There is nobody currently working on a major overhaul of PB, but that 
doesn't meant that further development is prohibited.  If you have 
specific features you would like added or bugs fixed in PB, you can feel 
free to contribute patches and we will integrate them (subject to the 
normal review process, of course).

That said, if Foolscap better suits your purposes, by all means use it!
>I hadn't been aware of AMP; after a quick look at the docs it seems a 
>bit low level for my purposes though, as I need to do more than just 
>send messages.

Since the FAQ of "isn't PB dead" has been raised yet again, I figure 
it's high time to give my own opinions of what's going on here.

AMP is intentionally low level.  AMP, PB, and Foolscap are, to me, at 
least, on a continuum where, on AMP's side, there is an extremely simple 
protocol implementing only the bare minimum required of an asynchronous 
messaging protocol.  On the other end, Foolscap is extremely complex but 
featureful.

This makes AMP ideal for applications where there is a narrow interface 
where two parties have to exchange a few simple and well-defined 
messages, with each party potentially being implemented many times by 
different languages and environments.  There are already ad-hoc AMP 
implementations in a half a dozen languages already (I myself have 
prototyped elisp and Java implementations) and they are so easy to do 
that I'm sure more are on the way.  You can do one yourself if you want.

PB falls somewhere in the middle; using PB involves understanding fewer 
concepts than using Foolscap (in particular, it has no concept of URLs 
or object-spaces like tubs) but provides commensurately fewer features. 
It has conveniences like deep object serialization.  It's well defined 
enough that you *can* write implementations for other languages if you 
really want to (there's one that mostly works for Java) but it's not the 
trivial affair that knocking off an AMP implementation is.  PB was 
originally designed to support shared simulation spaces (online games) 
where lots of clients talk to a server about a potentially complex graph 
of objects, and that's where it remains ideal.

Foolscap is geared towards very complex distributed applications where 
you need to serialize deep objects and coordinate arbitrary numbers of 
hosts which are connected in a mesh configuration.  There's only the one 
implementation, but if you have an application that is well-suited to 
foolscap, the application itself is probably hard enough to implement 
that you won't be worrying about integrating alternative implementations 
for quite a while.

Personally I've been more focused on AMP in the last year because I 
think there are currently a lot of applications in that first category 
which are currently being poorly served by bloated, complex, text-based 
protocols like XMLRPC, SOAP, and XMPP.  However, this mostly represents 
a shift in my personal area of interest, and is not a comment on the 
validity of either of the other two application domains.

That said, there may one day be some convergence or refactoring where a 
future version of PB becomes a layer on top of AMP, but given the 
obvious lack of any *application* drivers for such functionality, that 
seems like it will be very far off indeed.




More information about the Twisted-Python mailing list