Hi Mike, Thanks for the feedback.
On Sat, 2005-01-08 at 13:47 -0500, Michael Becke wrote: > I think we would want both individual component jars as well a > monolithic jars for things like http-client. > Agreed. > My preference would be for 1.4 unless there is a major feature in 1.5 > we cannot live without. I can't think of one at the moment. > I think we should hold a poll among HttpClient users and make a decision based on the results of the poll. I also tend to favor Java 1.4. > If no commons-logging, what would we use instead? UGLI? Something > custom? I have been thinking about not doing logging in the http-common at all. Trivial method entry/exit traces can/should be added by using an aspect of an AOP library. The context logging / wire logging _possibly_ could be exclusively done at http-client / http-proxy / http-server level. I am not absolutely positive it is technically feasible, though. Not having http-common tied to a specific logging toolkit may prove beneficial if it ever comes to trying to "sell" it to other projects, such Tomcat > Are you envisioning something similar to servlet filters? Would we use > this internally to handle cookies, authentication, etc.? > Pretty much. The cookie handling, authentication, redirect handling implemented as a bunch filters is an idea worth exploring. > logging seems to be an issue in general. Whatever we choose, I think > we need to be consistent and use the same logging at all levels. > Agreed. Still, I would rather have logging aspects inserted at a higher level, for the same reason mentioned above. > This has been discusses in other threads, but do we want to keep NTLM > or should we make it dependent on an external package like JCIFS? My > preference would be to externalize this feature. Same here. The trouble is we may have to keep some sort of NTLM support internally, should the ASF decide to prohibit the direct use of LGPL software > > depends on > > - commons-pool (needed? vote?) > > We could, but I'm not sure it's necessary. > I do not have a strong opinion here. We can still provide it as an option out of the contrib package. > > http-proxy > > -------------------- > > depends on > > - Java 1.4 > > - geronimo-network (appropriate? better options? vote?) > > Don't know anything about geronimo-network. What would this add? > The network protocol stack: http://svn.apache.org/viewcvs.cgi/geronimo/trunk/sandbox/network/src/java/org/apache/geronimo/network/protocol/ Of course, writing a protocol stack can be a great fun, but I doubt we can outdo the Geronimo folks. Unless geronimo-network comes with all sorts of unnecessary dependencies we should try to reuse it > Should we still be called HttpClient? If we have a simple server, a > client, a spider, etc., it seems we're more that just a client. > Sure. At the same time I think http-common, http-cookie, http-auth and http-client will completely absorb our existing resources and will keep us busy for months if not years. As soon as there's enough work done on server-side components we can consider rebranding. Until then let us not create too much confusion unnecessarily. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
