launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

I think whatever protocols we use, we probably want a thin policy
layer on the client, on top of whatever the stock client layer is.

This can handle:
 * retry of idempotent transactions - several Velocity speakers made
the point that they found it very helpful for robustness to have
services abandon and retry internal transactions fast enough they
could still meet their own external service level (obviously you need
some care not to cause chain reactions)
 * logging of what requests were sent, failed (in various ways) etc
 * manually or automatically tripped circuit-breakers to disable back ends
 * configuration of the address of service endpoints
 * perhaps handling some commonly used encodings
 * mapping errors into something clean, so application code doesn't
have to deal with socket.error (which is fairly cryptic in Python)

A lot of this is somewhat deployment specific and I don't think any
standard protocol client handles it.  (Though there might be a
standard wrapper we could use.)

Of course they don't have to be there at first but having a layer to
add them seems better than random application code directly caling
into urllib, zeromq or whatever.

Regarding xmlrpc, my basic point is that it's just a special case of
http, with some decisions already made for you:
 * you must send xml, which deals poorly with bulk data and binaries,
and which is verbose and not so easy to encode
 * it doesn't distinguish between readonly, idempotent, and
non-idempotent requests; at the conceptual interface level you
probably do know which is which and it's unfortunate to lose that
 * and related to that, it's always POST which limits what you can do
at the internal HTTP level
 * it encourages you to think of remote operations as procedure calls
which is probably not the best paradigm
 * it doesn't particularly help with the list above
 * it's kinda out of fashion ;)

m