Re: [AsyncWeb] Client redesign

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Jan 29, 2008, at 2:25 PM, Mike Heath wrote:

> Now that Alex has an AsyncWeb subproject going, I've finally taken the
> time to look over the client code.  I have some feedback about the
> client and what I would like to see change.  We also discussed the
> client on IRC and I will summarize some of the things we talked about.
>
> IoConnector Management - I really don't like how each AsyncHttpClient
> has it's own o.a.m.core.IoConnector instance which is used for a  
> single
> connection.  This has been discussed quite a bit but along the same
> vein, the IoHandler should also be a singleton and the state should be
> stored in the IoSession.  Additionally, it should be possible to  
> pass an
> instance of o.a.m.core.IoConnector so that the APR transport can be  
> used
> (or any other transport that comes along for that matter.)
>
> Connecting - Connecting is done as a blocking operation.  In Jeff
> Geneder's AHC branch in the Geronimo sandbox, thread pools are being
> used for asynchronous connecting.  This is unfortunate since MINA
> already has this functionality and does it in a much lighter weight
> manner than using a thread pool.

Interesting.  Can you provide more detail?

> Completion Notification - With the existing AHC, there's a single
> callback for the Client.  I REALLY like the observable future pattern
> that MINA uses.  With each asynchronous operation, a future object is
> returned.  This future object can be used to block until the operation
> completes.  The future is also observable so you can also register one
> or more completion listeners with the future.  This makes it real easy
> to do a fork/join like operation like:
>
> future1 = doAsynch1();
> future2 = doAsynch2();
> future3 = doAsynch3();
>
> future1.await()
> future2.await()
> future3.await()
>
> or use an event driven approach like:
>
> doAsynch1().addListener(...);
> doAsynch2().addListener(...);
> doAsynch3().addListener(...);
>
> This provides maximum flexibility.  This should be incorporated into
> AsyncWeb client.

I also dislike the single handler for the existing AHC.  Future  
objects seem like a nice idea.

> This topic came up on the IRC channel and David Lloyd (dmlloyd), Tuure
> Laurinolli (tazle), and I (mike_heath) were discussing better
> alternatives to the current design.  The following is a summary of our
> conversation.
>
> David posted this mockup as a possible future API
> http://rafb.net/p/P8GLTg85.html  David wanted me to be sure to note  
> that
> the class names in the mockup are just for purposes of explanation may
> change.

The paste seems to have expired.  Could you post it on to confluence?


Regards,
Alan