Folks, As you may know I am in the process of putting the final touches on the RFC2965 cookie spec contributed by Samin Jain. I believe it will be ready to be merged down into the trunk sometime next week. Samit did a pretty good job on that spec and contributed a few good ideas, which should be applied to other cookie specs in 4.0.
At the same the deficiencies of the existing cookie management API have become very evident. I have to assume responsibility for having added a couple of methods to the CookieSpec interface in 3.0 to solve some immediate problems, some of which were clearly ill-conceived. 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. 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. What do you think? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
