On Sun, 2007-05-27 at 19:18 +0200, Roland Weber wrote: > Hi Oleg, > > > As step 4 I moved all param hierarchy building logic from > > Http*Connection classes to the corresponding HTTP service classes. > > Cool, thanks. > > > Now, please hear me out. The only place where #setDefaults is being used > > outside HttpCore is DefaultClientRequestDirector. Can we _please_ move > > those bits of code back to HttpRequestExecutor? This would effectively > > encapsulate all param hierarchy building logic inside o.a.http.protocol > > package and would enable us to keep it internal to HttpCore protocol > > level code. > > In 3.x, we have at least two hierarchies: > > global -> client -> host config -> method > global -> client -> conn mgr -> connection > > I still see two cases for hierarchies in 4.x: > > [application ->] client -> request > [application ->] client -> conn mgr > > Even without application-wide defaults, o.a.h.protocol > will not encapsulate _all_ param hierarchy building. > I'm thinking of a class ClientParamsStack that has room > for at least request-, client-, and application-params. > I'm not sure yet how connection manager params fit in. > The connection operator expects parameters in method > calls. Those could reasonably be made client-specific, > with conn mgr params providing defaults. > > > This also gives up an option to replace the #setDefault > > stuff with a solution based on a private class StackedHttpParams or some > > such. _Please_ > > You meant to write "give us" rather than "give up"? > If HttpRequestExecutor is the only place in core that > still calls setDefaults(), yes, I can live with that. > Provided that we update the JavaDocs for HttpParams, > indicating that the behavior of setDefaults is > implementation dependent. > As mentioned above, I expect that params hierarchy > building will appear in DefaultHttpClient, in the > constructor as well as in the execute methods. The > advantage of keeping setDefaults() in core is rather > that the NIO code can remain unchanged. >
All right, If you foresee param building being used elsewhere besides Core, I'll step back and let you complete the refactoring. > > I also would like to remove HttpParams parameter from > > HttpClientConnection#receiveResponseHeader and > > HttpServerConnection#receiveRequestHeader methods if you do not mind. > > If those parameters are not used to customize the > receive operation, I don't see a need for them. > Where are limits for header size and such stuff > taken from? > They are set when the connection is initialized (bound to a socket) 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]
