>> src/java/org/apache/commons/util/http/BrowserDetector.java >> src/java/org/apache/commons/util/http/HttpUtils.java >> src/java/org/apache/commons/util/http/RequestUtils.java > > There's been suggestion for a 'servlet' package. These > might go in there
That sounds like a better idea still, since even if HttpUtils/RequestUtils can make their way into HttpClient, BrowserDetector would still be orphaned. -----Original Message----- From: Waldhoff, Rodney To: 'Jakarta Commons Developers List ' Sent: 2/21/02 10:48 AM Subject: RE: Commons Util 1.0 release candidate 1 Bay wrote: > This leaves a few other classes to > decide where they should go. > 2) http. I imagine this would either > go into io or into HttpClient. io seems > most likely as HttpClient has a > different goal. IO sounds OK, but we may want to revisit that. I'd like to see us factor out some of the HTTP parsing/generating bits in HTTP Client so that they're usable independent of the wire-level protocol (driven by some experiences using an in-process Tomcat engine), in which case RequestUtils and HttpUtils might be clean fit. (I'm gonna send out a note on this and some related HTTP Client (3.x?) ideas, probably next week.) (I'm actually a little confused by the purpose of RequestUtils: shouldn't header matching just be a matter of case-insensitive comparision? Can someone point to where/why RequestUtils is used?) > 3) 'util' like classes. > Soundex > Soundex is used by Strings(StringUtil) so it's > tempting to send it with it into Lang. Soundex seems like an String encoding to me, so why not in the codec component? - Rod
