From: Greg Wilkins <gregw_at_webtide.com>
Date: Thu, 3 Dec 2015 08:00:20 +1100

On 3 December 2015 at 01:12, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:

> Sure there are neat ways for them to do it but in the blocking model we
> provide helper methods for parsing parameters whereas in the non-blocking
> model we do not


I think on balance, I agree that we should provide a mechanism for such a
common operation. But if we go that way, then we also provide multi-part
support on the blocking request, so we may need to provide that as well
asynchronously.

Note also that the reactive stream suggestion is not necessarily saying
that is a framework thing. I have suggested before that we look at
including the RS model in the servlet API as a better way to handle async
data flows, since it is going to be in the JVM.

This is a good example of why something like RS should be considered,
because while your Options both look OK, their lack for flow control
support is a significant shortcoming. I think those options need to be
morphed into something that operates in the same isReady() loop/callback
style of the ReadListener, which provides both flow control and help to
avoid deep callback recursion. Perhaps something like:


interface ParameterListener
{
   void onParameterAvailable(Stream stream};

   public interface Stream
   {
      boolean isReady();
      Map.Entry<String,String> getParameter();
   }
}

This would be used in similar style to ReadListener:

MyParameterListener
{
  public void onParameterAvailable(Stream stream)
  {
    while(stream.isReady())
      myConsumeParam(stream.getParameter());
  }
}



Semantically this style is similar to RS, where the isReady() call is
equivalent to a request(1) call in RS that provides the back pressure
control. The servlet style is better in that it has better recursion
control (RS has the problem of request(n) calling onNext calling request(n)
calling onNext etc.



Multi part could be similar with callbacks for onPartAvailable:


interface MultiPartListener
{
   void onPartAvailable(Stream stream};

   public interface Stream
   {
      boolean isReady();
      Either<File,Map.Entry<String,String>> getPart();
   }
}

or maybe


interface MultiPartListener
{
   void onPartAvailable(Stream stream};

   public interface Stream
   {
      boolean isReady();
      boolean isFilePart();
      boolean isParamPart();

      Map.Entry<String,String> getParameter();
      File getFile();
   }
}


So in summary, I'm not opposed to making the supported functionality in
async mode match that of blocking mode, but if we do so it needs to support
back pressure and to be a near complete match to the blocking functionality.

cheers

-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com