mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [AsyncWeb] Client redesign
Date Sun, 10 Feb 2008 16:48:01 GMT

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





Mime
View raw message