Neil Tenenholtz

A few thoughts: * One option is to enforce the retry policy via proxy (e.g., a sidecar like envoy) rather than in code. This tends to make the enforcement of...

@hackermd, thoughts on allowing the user to pass an optional sequence of decorators which would wrap all of the http calls? would decouple the retry logic, streamline the addition of...

FWIW @pieper, an easy way to ensure backwards-compatibility would be to: 1. retain `set_retry_params` with its current signature 2. allow the user to supply decorators, either upon creation or via...

Currently, `DICOMwebClient` has three methods named: * `_invoke_get_request` * `_invoke_post_request` * `_invoke_delete_request` I'm proposing that these methods retain their current signatures and that the user be allowed to supply, via...

As @pieper stated, header manipulation (auth, tracing, etc), logging, retry ... the list goes on. Regarding the exposing of internal details, I'd argue url, body, and headers are fairly generic...

Honestly, to me this is not at all about functional vs object-oriented programming, but rather, providing flexibility to the user without the need to create derived classes as well as...

>How would that really be different with a decorator? The user would have to implement a decorator that wraps requests.session.Session.request instead of defining a type derived from (or with the...

I believe there are two axes worth distinguishing and worthy of discussion here. * _**Request vs Response**_: As you alluded to, one could create a set of hooks which are...

Have only used it in passing, but another option to explore may be [requests toolbelt](https://toolbelt.readthedocs.io/en/latest/threading.html).

Are you looking to make it async or merely parallelizable? If you're looking to maintain API compatibility between the clients (a nice-to have, but certainly not mandatory), * requests-toolbox may...