>>>>> On Tue, 1 Dec 2015 18:12:19 -0500, "Martin Mulholland" <mmulholl_at_us.ibm.com> said:
MM> With the introduction of async i/o in Servlet 3.1 it is now possible for
MM> applications to read post data asynchronously. However applications which
MM> process parameters sent as post data can only take advantage of async i/o
MM> if they are willing to parse the parameters themselves without use of the
MM> convenience methods provided by ServletRequest.
That is indeed a significant usability failure.
MM> I propose this is addressed and we provide a method for applications to
MM> receive parameters as post data using async i/o without having to do their
MM> own parsing. There are many ways to do this. My suggestions are:
MM> Option 1. Add a new parameterListener object with methods
MM> onParameterAvailable, onAllParametersRead, and onError (same equivalent
MM> methods as a readListener). It could be registered with the input stream
MM> just like readListener.
>>>>> On Wed, 2 Dec 2015 10:49:11 +1100, Greg Wilkins <gregw_at_webtide.com> said:
GW> I'm torn between thinking: - "there are many ways to do this, so why should
GW> we pick one? Isn't this a framework's job" vs "We've picked lots of
GW> other 'favourite' solutions in the spec, so we should do this as well".
GW> If we want to support this, then your Option 1 is OK other than its lack of
GW> flow control (see below)
[...]
GW> I've still not used reactive streams enough to say I actually like them....
GW> but they are destined for the JDK... so perhaps they are a good choice even
GW> if we don't luv em?
Yes, it seems Reactive Streams have carried the day and I think we
should plan for them.
>>>>> On Wed, 2 Dec 2015 09:12:53 -0500, "Martin Mulholland" <mmulholl_at_us.ibm.com> said:
MM> reactive streams are new to me but look interesting. I like your examples
MM> but my point is that we have dumped the complexity of parsing parameters
MM> on applications if they want to receive them as post data using
>>>>> On Thu, 3 Dec 2015 08:00:20 +1100, Greg Wilkins <gregw_at_webtide.com> said:
GW> I think on balance, I agree that we should provide a mechanism for such a
GW> common operation. But if we go that way, then we also provide multi-part
GW> support on the blocking request, so we may need to provide that as well
GW> asynchronously.
Right, I agree that we need it and I agree that we need to do multi-part
async and blocking.
GW> Note also that the reactive stream suggestion is not necessarily saying
GW> that is a framework thing. I have suggested before that we look at
GW> including the RS model in the servlet API as a better way to handle async
GW> data flows, since it is going to be in the JVM.
GW> This is a good example of why something like RS should be considered,
GW> because while your Options both look OK, their lack for flow control
GW> support is a significant shortcoming.
In this day and age, the lack of back-pressure is a non-starter. It's
almost like when the "builder" API style came along and everyone started
to think, "hey, if I have to do a new API, I better do it using the
builder style, if appropriate". In other words, there's no excuse for
not having first-class support for reactive style when adding new
features to an IO related API.
GW> I think those options need to be morphed into something that
GW> operates in the same isReady() loop/callback style of the
GW> ReadListener, which provides both flow control and help to avoid
GW> deep callback recursion. Perhaps something like:
GW> interface ParameterListener
GW> {
GW> void onParameterAvailable(Stream stream};
GW> public interface Stream
GW> {
GW> boolean isReady();
GW> Map.Entry<String,String> getParameter();
GW> }
GW> }
This and your other examples beg the question: how do we depend on
Stream when our maximum JDK level is SE 8?
[...
GW> So in summary, I'm not opposed to making the supported functionality
GW> in async mode match that of blocking mode, but if we do so it needs
GW> to support back pressure and to be a near complete match to the
GW> blocking functionality.
But can we support back pressure without introducing a dependency on the
actual Streams API?
Thanks,
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017