Features:
I think this will be the headline feature for our 3.0 release.
In today's OkHttp:
http/1.1 synchronous calls do blocking writes and blocking readsspdy and http/2 synchronous calls do blocking writes; and read from an in-memory buffer that's bounded by window management.For 3.0, I'd like to introduce a better dispatcher that works for all protocols, using spdy-style thread management for all HTTP calls. The dispatcher would own caching, joining, and server-push. It would take over some responsibilities from HttpEngine, and hopefully cause the HttpTransport interface to shrink dramatically.
Internally, dispatcher's model is interested in tracking which requests are currently in flight, and who those requests service. It needs to use each cache entry as a coordination point between callers, so that two callers requesting the same cached resource yield only one network call, even if the 2nd call is made before the first completes.
I think this will be the headline feature for our 3.0 release.
In today's OkHttp:
* `http/1.1` synchronous calls do blocking writes and blocking reads * `spdy` and `http/2` synchronous calls do blocking writes; and read from an in-memory buffer that's bounded by window management.For 3.0, I'd like to introduce a better dispatcher that works for all protocols, using spdy-style thread management for all HTTP calls. The dispatcher would own caching, joining, and server-push. It would take over some responsibilities from HttpEngine, and hopefully cause the HttpTransport interface to shrink dramatically.
Internally, dispatcher's model is interested in tracking which requests are currently in flight, and who those requests service. It needs to use each cache entry as a coordination point between callers, so that two callers requesting the same cached resource yield only one network call, even if the 2nd call is made before the first completes.
Has this been implemented in OkHttp3?
We'll close the issue when it's done.
Any updates on this? The comment here states that this was fixed.
The thread changes have fed through. Any work here is probably behind coroutines support on kotlin.
Most helpful comment
We'll close the issue when it's done.