On Wed, Jul 29, 2015 at 12:07 PM, Edward Burns <edward.burns_at_oracle.com>
EB> I'd like to take the opportunity presented by this blog post to sketch
EB> out a plan to have an Early Draft Review (EDR) of the specification
EB> available in time for JavaOne 2015. In my opinion, we need to specify
EB> the following features in order to have something worth calling an EDR:
EB>
EB> * HTTP/2 Server Push
EB> * Inclusion or intentional ignoring of Reactive Streams
>>>>> On Fri, 31 Jul 2015 11:01:32 -0700, Wenbo Zhu <wenboz_at_google.com> said:
WZ> FYI - the discussion on http 2 client api
Thanks for alerting us to this most recent tributary of discussion on
the API design for HttpClient in JDK 9.
WZ>
http://mail.openjdk.java.net/pipermail/net-dev/2015-July/thread.html#9046
WZ> Seems useful if the client and server follow the same model
I've been following the development of Michael McMahon's API closely,
and also communicating with him about implementation reuse. While I
like the elegance of the BodyProcessor model, I think such a model would
be too radical a departure for our mature Servlet API.
WZ> and often servers need proxy data too (even when the downstream rpc
WZ> protocols are different).
What do you mean by "need proxy daya too"?
Are you referring to Simone Bordet's text here:
SB> In my experience, one important use case to design the API for
SB> request (and response) body processing is the proxy use case. In
SB> particular, the API must allow an implementation to provide
SB> backpressure. Imagine a proxy, where HttpClient is used in a webapp
SB> to proxy requests from a client to an upstream server, reading
SB> byte[] from ServletInputStream and sending these bytes to the
SB> upstream server. If writing to the server is slow and blocks, we
SB> don't want to read anything from the client until we know we can
SB> write more to the server, thus providing backpressure. This
SB> typically means that we need some sort of "callback" associated with
SB> the ByteBuffer to signal that the ByteBuffer has been written to the
SB> server, and resume reading.
[...]
SB> A typical solution is to use a Callback interface (or
SB> CompletableFuture), so that the pair (ByteBuffer, Callback) is
SB> considered a single unit of what is provided for reads and
SB> writes. Another solution would be to look at the reactive stream
SB> APIs that seem to be scheduled for inclusion in JDK 9 via the Flow
SB> class proposed by Doug Lea.
For the record, this proposal is at <
http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013641.html>.
[...]
SB> FWIW, we're discussing with the Servlet 4 EG about introducing a
SB> reactive stream API for Servlet 4 async I/O. Not yet carved in
SB> stone, but it's getting a little traction.
By "a little traction" Simone is referring to my email last Wednesday as
well as a couple emails Greg Wilkins and I exchanged. I'll start a
separate thread about Reacive Streams so we can give this some more
traction.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 65 Business days til JavaOne 2015
| 80 Business days til DOAG 2015