P4
The Flow based BodyProcessor API is still difficult to implement.
Developers have no control over the size of the ByteBuffers handed to them.
For example,
- an application that loads an image may want to first load the image header
(some fixed size of N bytes), followed by the image body if chunks that are
multiples of some number of M bytes. ⇨ ExampleUseCases.downloadImage() .
- a block cipher (e.g. AES) works on chunks of some fixed size. ByteBuffers
that are not multiples of that size, or are not aligned to chunk boundaries,
need to be copied/stitched together by the application.
- The number 'n' of desired callbacks passed to subscription.request( n ) is
almost meaningless because it doesn’t represent any particular amount of
data. As a consequence, the provided implementations in OpenJDK (and
probably most apps) never pass values n other than 1 or Long.MAX_VALUE.
Suggestion:
Give applications control over the size of the ByteBuffers that are delivered, e.g.
by the application supplying the ByteBuffer objects (as in Chrome’s networking
stack, Cronet [1]) or requesting a number of bytes (instead of # of callbacks) [2].
Sadly, neither works well with the Flow API. If apps supplied the ByteBuffers,
they could also have a choice of implementation (e.g. MappedByteBuffer).
Would it make sense to configure the buffer size through the HttpClient
(perhaps allowing a different size for the first buffer vs. subsequent buffers)?
[1] https://chromium.googlesource.com/chromium/src/+/lkgr/components/cronet/
[2] ⇨ See comment in PipedResponseStream.PullBodyProcessor.onSubscribe()
This issue has been filed to capture comments raised by tobiast at google dot com, see
http://mail.openjdk.java.net/pipermail/net-dev/2017-July/010872.html
Developers have no control over the size of the ByteBuffers handed to them.
For example,
- an application that loads an image may want to first load the image header
(some fixed size of N bytes), followed by the image body if chunks that are
multiples of some number of M bytes. ⇨ ExampleUseCases.downloadImage() .
- a block cipher (e.g. AES) works on chunks of some fixed size. ByteBuffers
that are not multiples of that size, or are not aligned to chunk boundaries,
need to be copied/stitched together by the application.
- The number 'n' of desired callbacks passed to subscription.request( n ) is
almost meaningless because it doesn’t represent any particular amount of
data. As a consequence, the provided implementations in OpenJDK (and
probably most apps) never pass values n other than 1 or Long.MAX_VALUE.
Suggestion:
Give applications control over the size of the ByteBuffers that are delivered, e.g.
by the application supplying the ByteBuffer objects (as in Chrome’s networking
stack, Cronet [1]) or requesting a number of bytes (instead of # of callbacks) [2].
Sadly, neither works well with the Flow API. If apps supplied the ByteBuffers,
they could also have a choice of implementation (e.g. MappedByteBuffer).
Would it make sense to configure the buffer size through the HttpClient
(perhaps allowing a different size for the first buffer vs. subsequent buffers)?
[1] https://chromium.googlesource.com/chromium/src/+/lkgr/components/cronet/
[2] ⇨ See comment in PipedResponseStream.PullBodyProcessor.onSubscribe()
This issue has been filed to capture comments raised by tobiast at google dot com, see
http://mail.openjdk.java.net/pipermail/net-dev/2017-July/010872.html