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 19:49:56 GMT

On Feb 10, 2008, at 10:35 AM, David M. Lloyd wrote:

> Alan D. Cabrera wrote:
>> 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);
>
> This is a departure from the rest of MINA though, in which the idiom
> is more like this:
>
>  ahc.send(request).setListener(listener);  // does not block
>
> or:
>
>  ahc.send(request).get(); // blocks
>
> using IoFuture and similar objects.  I think it would be wise to  
> remain
> consistent with the MINA idiom in this case.  This method has the
> advantage of using java.util.concurrent-style future objects as well  
> as
> listeners as proposed above.

Ok, makes sense to me and there's great value at carrying on that  
convention in AHC.


Regards,
Alan


Mime
View raw message