On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote:
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
4) Future objects for any blocking operation
I was thinking that we could have a Future object that implements an
AHC callback interface. This would keep the client simple. Those
needing synchronous mechanisms could drop in an instance of this
Future object. Just trying to prevent something like:
ah.doThisWay().addListener(bar);
foo = ahc.doAnotherWay();
foo.await();
So, I was thinking that you would send requests like so:
ahc.send(url, listener);
I realize that URL could be in a request object but I've left that
bit, which might need further discussion, out for the sake of this
discussion. I'm also starting w/ the Geronimo AHC because I am most
familiar with it.
To use a FutureResponse<V> object which implements
AsyncHttpClientCallback one would:
FutureResponse<ApplicationResponse> futureResonse = new
FutureResponse<ApplicationResponse>(builderListener);
ahc.send(url, builderListener);
Here the send call would see that it's being passed an instance of
FutureResponse and inject the information that the FutureResponse
needs to be able to cancel the request. The listener builderListener
is quite different from the former listener. It actually builds the
ApplicationResponse from HTTP response and calls setValue(V value).
This releases a latch for any call to V get() to proceed. Calls that
return nothing could always use Void.
The cool thing about this is that the API stays clean while obtaining
much more power.
Regards,
Alan
