On Mon, 2006-05-01 at 11:35 +0200, Roland Weber wrote: > Hi Oleg, > > > 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. > > from a coding perspective, it should not be significantly more effort to > have several components instead of one. I assume that the problem is to > set up the new components with their own web(sub)site, subversion tree, > and JIRA project? It takes you several weekends to create a new component, > and creating three more would keep you from coding for another few months. > > Is this assumption correct? Because if it is, I would suggest to not > give up our goal of having independent components at this time. It's > mainly a question of priorities and phrasing. Instead of removing the > stubs for the new components from the web site, we could simply add a > notice: > > "Due to resource constraints, the code for HttpXxx will be developed > and maintained as part of the HttpClient component, until somebody > is willing to spend the effort of creating a separate component. > Setting up a web site, subversion tree, and JIRA project takes many > days. We currently prefer to invest this time into the code base." > > If we keep the components separate from a design/conceptual perspective, > creating the missing components is just an administrative task that can > be done whenever somebody feels like it. If we officially fold these > components into HttpClient, factoring one of them out requires a new > discussion. >
Roland, Nothing is carved in stone until HttpClient 4.0 API is frozen. Presently it is just too much of a managerial burden to maintain cookie, authentication and connection management aspects as separate modules. The whole idea of HttpComponents was to reduce coupling between distinct sets of components within HttpClient in order to lower the entry barrier for new contributors by allowing them to concentrate on specific HTTP aspects without having to deal with intricacies of the entire HTTP stack. By factoring out low level transport aspects into HttpCore we have already made a good progress toward this goal. Until we get more people on board I do not think splitting things further into HttpCookie, HttpAuth, HttpConn helps that much. They are already completely decoupled. Maintaining those components as separate modules will just put extra burden on the actual committers and will result in more JARs the users will have to download and deal with. We should not do it unless it is clearly driven either by demand from the users or by contributions from new project participants willing to help maintain those components. Let us be pragmatic. Those new contributors may never materialize. Cheers, Oleg > cheers, > Roland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
