I'm curious. Why HTTP::Async? While it does look to make async calls, I have to admit that I've never seen it before. Not that, by itself, that's a good reason, of course :-) I would have expected the natural method for moving HTTP requests to be asynchronous to be threads. And then there's the new fad going around of using Coro (which I only started using within the last couple months). If you check that link, you'll see I'm actually using AnyEvent::HTTP to do the async HTTP requests (and then doing funny things with them to invert the control back away from call-backs).

Of course, this necessitates that you adjust (somewhat) to using a different model for your development, whether that be threading (and the fun parts of sharing variables such that they work), or event-based programming in general, or Coro (usually with events). However, the big plus to all of these options, in my opinion, is that they scale - they are methods of development that work well for many things, including, but not limited to, asynchronous HTTP requests. You can do lots of things asynchronously (I'm also doing DB fetch/store asynchronously thanks to Coro::DBI), all with the same mindset. HTTP::Async looks neat, but what you learn from using it won't be directly useful in other situations. And, while I expect HTTP::Async to likely work in a single thread (i.e., a single thread that queues a bunch of requests), it may not mix with Coro or AnyEvent very well.

Don't change just because I say so (I'm just some random schmo on the internet whose real name you don't know, and, even if you did, it would be meaningless, I'm no merlyn or chromatic or any other author that hangs out here from time to time). I'm just suggesting these as useful additions going forward if you need more async stuff.