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
