[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
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
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