switching boto to use truncated exponential backoff

[Michael Schwartz]

Hi,

Currently boto uses binary exponential backoff in a number of places. I'd like to switch it to use truncated exponential backoff (doubling the backoff delay each time but maxing out at a config-settable value).

Google Cloud Storage only uses the boto exponential backoff implementation in third_party/boto/boto/connection.py; however I propose changing all of the places in boto that do exponential backoff (route53, dynomdb, etc.) to use truncated exponential backoff, so boto behavior is consistent.

Does anyone have thoughts or concerns about this?

Thanks,

Mike