Hi Oleg, > While I am at it and all the ideas are fresh in my mind I would like to > take a first stab at the refactoring of the cookie management API.
Great. Go for it! > More importantly, though, I would like to suggest a few organizational > adjustments. I am concerned we have been spreading our limited resources > too thin with so many modules in HttpComponents and two branches of > Commons HttpClient. I want to suggest that we put on hold the plans to > develop separate HttpCookie, HttpAuth, HttpConn modules for the time > being and fold them into HttpClient until we see some demand for those > modules to be developed and released independently. That should leave us > with 5 modules to manage (HttpCore, HttpAsync, HttpNIO, HttpClient, > NoRobots), which should be sustainable. More modules can always be spun > off if we get more people on board. I am concerned regarding the dependencies between HttpClient and HttpAsync. HttpAsync will need connection management, while at the same time I am still aiming for an HttpClient that offers asynchronous functionality. Merging HttpConn into HttpClient would introduce a recursive dependency. However, I do not object against developing HttpConn functionality as part of HttpClient for the time being, for the following reasons: - connection management functionality required by HttpAsync will have a very different interface than for synchronous communication. I was not sure how HttpConn and HttpAuth would relate to eachother anyway. - I am months away from the point where HttpAsync could make use of connection management. Once I'm there, we can still decide how to organize the code. For example, we can have async style connection management implemented in HttpAsync, then consider refactoring. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
