You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently chopper has a lot of ways for defining a interceptors. Interceptors can also be of different types. The current setup is easy to understand and implement. But its difficult to extend internally.
Adding for example a new feature request like #334 is difficult because changing all interceptors after creation has the issues that interceptors are split into different type of interceptors (request and response). So we has to look for ways to right order of both set of requests. Or add separate function for updating request and response interceptors.
Another example is #284 timing request is currently not really possible for logging purpose. While the logging interceptor implements both interfaces (request/response interceptor) the calls to the interceptor aren't linked in any ways which make tracking of elapsed time near impossible.
Mostly I want to discuss the right way forward for chopper.
Describe the solution you'd like
Drawing inspiration from OkHttp it might be possible to change the interceptor working into a chain of interceptors. In the chain the request first go through the the list of interceptors where each interceptor has the possibility to change the request. When the request is send and the response is received the response goes backwards through the interceptor chain. And this time the interceptor have the possibility to change the response object if needed. This approach also means the internal bit of chopper need to change but could also benefits and make use of this chain. For example doing the conversion of request/response or formatting of headers could be a internal interceptor with a simple responsibility. This could also make the internal code base easier to understand.
See the RealCall as example what is done with OkHttp.
This would reduce the amount of different type of interceptor interfaces. A interceptors can change both the request and the response. This would make it easier to swap interceptors after the client is created and also add the possibility to time requests within a simple interceptor (Logging interceptor for example).
Describe alternatives you've considered
None.
Additional context
I have played around with this concept I think this is certainly possible but not without some breaking changes. I tried to make it work without breaking much of the current functionality but I doubt that is really possible. For example its now possible to have Functional interceptors in the interceptor list when creating the chopper client. I couldn't manage get that working properly with passing <BodyType,InnerType>.
Another benefit could be to possible a support for different http packages. (Not the goal) When the internal structure is abstracted into separate interceptor the final executing interceptor responsible from the actual http call could also be swapped. But this is just dreaming hahaha. And need a lot more work.
A small snippet from what I playing with.
Starting the chain (basically the sent function in base):
Is your feature request related to a problem? Please describe.
Currently chopper has a lot of ways for defining a interceptors. Interceptors can also be of different types. The current setup is easy to understand and implement. But its difficult to extend internally.
Adding for example a new feature request like #334 is difficult because changing all interceptors after creation has the issues that interceptors are split into different type of interceptors (request and response). So we has to look for ways to right order of both set of requests. Or add separate function for updating request and response interceptors.
Another example is #284 timing request is currently not really possible for logging purpose. While the logging interceptor implements both interfaces (request/response interceptor) the calls to the interceptor aren't linked in any ways which make tracking of elapsed time near impossible.
Mostly I want to discuss the right way forward for chopper.
Describe the solution you'd like
Drawing inspiration from OkHttp it might be possible to change the interceptor working into a chain of interceptors. In the chain the request first go through the the list of interceptors where each interceptor has the possibility to change the request. When the request is send and the response is received the response goes backwards through the interceptor chain. And this time the interceptor have the possibility to change the response object if needed. This approach also means the internal bit of chopper need to change but could also benefits and make use of this chain. For example doing the conversion of request/response or formatting of headers could be a internal interceptor with a simple responsibility. This could also make the internal code base easier to understand.
See the RealCall as example what is done with OkHttp.
This would reduce the amount of different type of interceptor interfaces. A interceptors can change both the request and the response. This would make it easier to swap interceptors after the client is created and also add the possibility to time requests within a simple interceptor (Logging interceptor for example).
Describe alternatives you've considered
None.
Additional context
I have played around with this concept I think this is certainly possible but not without some breaking changes. I tried to make it work without breaking much of the current functionality but I doubt that is really possible. For example its now possible to have Functional interceptors in the interceptor list when creating the chopper client. I couldn't manage get that working properly with passing <BodyType,InnerType>.
Another benefit could be to possible a support for different http packages. (Not the goal) When the internal structure is abstracted into separate interceptor the final executing interceptor responsible from the actual http call could also be swapped. But this is just dreaming hahaha. And need a lot more work.
A small snippet from what I playing with.
Starting the chain (basically the sent function in base):
The interceptor chain:
The actual request internal interceptor:
The text was updated successfully, but these errors were encountered: