True async reading of ResponseBody

[herbyderby]

#873
added the ability to read the ResponseBody on a different thread "at your leisure" (i.e. not constrained to be entirely within the onResponse method).

However, the actual reading of ResponseBody is still blocking, whether via bytes(), byteStream(), or any of the methods on okio.BufferedSource. That can be a problem for long or slow requests.

For truly async processing of a request, there should instead be some callback/listener API that pushes the data to the application, or at least notifies it that more data is available to be read.

(It's possible that this makes more sense as a feature request for okio)

[swankjesse]

Yeah we've long been considering how to do this. The difficult part is that consuming data one block at a time is often quite ugly.

Maybe coroutines will save the day!

[herbyderby]

FWIW my use case is using okio as the implementation of a higher-level API (which uses Guava ListenableFuture), so it is more important that it is possible than elegant.

Here are some options to consider:

Option 1: new methods on okio.BufferedSource:

/** Returns how many bytes can be read without blocking (possibly zero). */
long available();

/** Requests the given number of bytes, invoking the callback when available. */
void requestAsync(long byteCount, Runnable callback);

Option 2: new method on okhttp3.ResponseBody (may require Option 1 anyway):

/** Passes data to the callback as it becomes available. */
void asyncStream(ByteCallback callback);

public interface ByteCallback {
  void onBytes(ByteString bytes);
  void onExhausted();
}

[swankjesse]

First steps:
square/okio#531

[yschimke]

Closing as low priority. Could be more relevant if we want to support a really nice JS API.