Hi Oleg, everyone, it is a good and usually neglected practice to summarize and discuss the "lessons learned" during a project at some time. I planned to do that later this year, but since the opportunity presents itself, I'll do it now. The project in question is HttpAsync, or rather the client side thereof.
I set out to contribute an API and initial implementation of HttpAsync last december. Since then, that has been the primary goal of my contributions to HttpComponents. When challenged with a task such as this at work, I would estimate an effort of about two weeks, excluding test cases. The result would not be as good as here due to the missing peer reviews - a lot of overdesigning and some "smelly code". Still, within two weeks, I could deliver something that works and is a good starting point for improvements in the next iteration. Since I'm not developing for HttpComponents full time, let's translate the two weeks to 10 weekends. That's a net effort of about three months. Obviously, there were some points I did not take into account. First, I needed a lot more time than expected to familiarize myself with the environment. Setting up accounts, learning new tools, all that took quite some time. I'm still not finished, but I'm at least at a point where I am no longer having urgent issues with the environment. Next, I had to realize that the peer review process slowed me down considerably. It's not so much coming up with a modified patch after some feedback, but more the waiting for the feedback. If I create a patch on one weekend and put it up on Sunday, the review will have to wait until the following weekend, and the next iteration of the patch maybe until the weekend after that. Estimated effort 1 weekend, elapsed time 3 weekends. Even worse when Oleg and I disagree and multiple iterations are needed. One way to deal with this is to work on several isolated items in parallel. But HttpAsync is too narrow a codebase for that, and males are reportedly bad at multitasking anyway :-) Then, I expected about half of my weekends to be blocked by my lectures, while it was actually more like two thirds. And finally, I spent considerable time working on HttpComponents other than HttpAsync. So where is HttpAsync now? It's a pity, but HttpAsync is still at the same point where it was when we concluded the discussion about the threading design. When I entered a new coding phase several weeks back, I wanted to deal with HTTPASYNC-1 and HTTPASYNC-2: https://issues.apache.org/jira/browse/HTTPASYNC-1 https://issues.apache.org/jira/browse/HTTPASYNC-1 The idea was to get these things out of the way to prepare for another coding phase around christmas in which I wanted to tackle the real issues. Now the current coding phase is basically over, and I have not achieved a single item on my list. What's worse, I don't see the situation changing for the next coding phase around christmas. Maybe, just maybe, I'll get HTTPASYNC-1/2 finished then, and start thinking about the next step. Several months behind the revised plan, which is already several months behind the previous plan. Sure enough, I've achieved other things. We have a new Ant based build process, and a lot of work has gone into HTTPCORE-11 and some into HTTPCORE-8. These are important items, that's why I gave them priority over HttpAsync. It's not like I wasted my efforts. And still: my declared goal is to contribute HttpAsync, and I have not made any measurable progress towards that goal. With all the activities necessarily going on in HttpComponents, HttpAsync is constantly dangling at the end of my to-do list. Meanwhile, it is also a constant drag on my mind, and not only during the coding phases. And that's why I want it gone from my to-do list. I want to drive a stake through HttpAsync/CS, now. Let's revisit the ashes some time in the future, to see whether a phoenix is hiding in there. When the prerequisites are in place. With the HttpAsync monkey off my back, I can set new goals like improving the other components, and fixing the problems we meet on the way. Accomplishable short-term goals. Goals that allow me to see some progress. This way, I will get a little more satisfaction and a lot less frustration out of my activities. > HttpAsync has not seen a single official release. There is no need to > make any declarations. Fair enough. No official declaration needed. Whack! *puff* > I have always been trying to say that controlled code duplication in > HttpAsync is a lesser evil because it can shield HttpAsync from API > instability in HttpCore. Go ahead and roll out an HttpAsync specific > extension of HttpClientConnection interface and its default > implementation. If I have to work on connection management code anyway, I prefer to do it for HttpConn. Let HttpAsync/CS rest in peace until the time is ripe for resurrection. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
