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
