XhrManager exponential backoff retries

[danielcompton]

XhrManager allows you to set retries for XHR requests, but it will immediately retry after every failure, rather than backing off and retrying in a few seconds. Would a patch to extend XhrManager to allow the choice of a retry backoff strategy fit with the goals of the Closure project?

There may be some good reasons for the current behaviour, so my apologies if this feature request is uninformed.

[shicks]

Yes and no - the behavior would be welcome, but I'm concerned about over-configurability and API design. The various XHR classes are a tangled mess that have been having their constructor parameters grow unbounded and between the pool and the manager there's lots of places where constructor parameters just get passed along to some other class...

If we could add the behavior in a sane way that doesn't add yet another positional parameter to a method that already takes 4+ parameters, then it's probably worth adding. Maybe an appropriate way would be a function that can be called repeatedly to return a delay (possibly with a parameter that's the number of tries so far) - then different retry strategies can be generated and/or composed. This is an awful lot like an Iterator, but we can't really use ES6 here (yet)...