On Sat, 2005-08-27 at 20:37 -0400, Henri Yandell wrote: > On 8/26/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-08-26 at 11:34 -0700, Gordon Mohr wrote: > > > I may have missed something -- but the answer doesn't seem to be in this > > > thread. > > > > > > What's wrong with 'HttpClient'? > > > > > > FWIW, this project under its current name 'owns' the term 'HttpClient' > > > via the major search engines; that's usually how I get to the > > > project pages for news, source dumps, etc. > > > > > > If the aim is to make a broader name to also encompass additional > > > related work, I would suggest some sort of extension to 'HttpClient' > > > preserving it as a name token, like 'HttpClient Toolkit' or some such. > > > > > Gordon, > > > > This is an unfortunate side effect of internal Jakarta politics. There's > > nothing wrong with the name. To a certain extent it is a brand. The > > trouble is that we might be not permitted to release server side HTTP > > components because some believe that may constitute a breach of the > > project charter (whatever that mean since we do not have a charter > > yet). > > A bit stronger than the current situation I think. There was a comment > on server-stuff being outside the Commons HttpClient charter, but as > Oleg pointed out, the Jakarta HttpXxxx charter is currently undefined. > > My opinion, which is pretty worthless though I do have a robots.txt > parser I'd like to contribute when you get setup for said components, > is that the name should be: > > HttpComponents > > and that you split said components into: > > * Http Client Components (maintaining name) > * Http Server Components > > on the navigation system. > > Naming yourself HttpComponents should help with two of the larger > confusions (ie - you won't be releasing a full HTTP server > implementation and you're not seeking to create an alternative to the > Servlet API). Not that either of those were considered outright bad, > just that we ought to talk with the ASF as a whole before doing them. >
Hen, This is my personal opinion, so take it for what it is worth. We do not even have to emphasize the server side of HttpComponents. The overlap between server-side and client-side code in HttpCommon (the set of low level HTTP primitives) is 95%. Out of approx 120 java classes only 7 (seven) represent server side logic. Just please let us bundle the remaining 5% to make the framework logically coherent and complete. It would be a shame to not do so. > Biggest problem with the above might be complaints from the Apache > HTTP Server project about the 'Http Server Components' subtitle, which > can either be solved by putting Java(tm) on the front or having a big > debate about rearranging the ASF :) > I personally would not see a very big problem in hosting all the server modules built on top of the HttpCommon, HttpAsync, HttpCookie, and HttpAuth (be it a Tomcat HTTP connector or a lightweight server) on the sourceforge.net, if that's the price to be paid to keep HTTPD and Tomcat folks happy. > - > > Two further questions: > > 1) Will you be releasing these components as separate jars? ie) is > HttpC**** about to become an umbrella subproject like > Taglibs/Commons/Turbine/Silk? > Very likely. We probably want to be releasing a full HttpClient package including all three dependent modules (HttpCommon, HttpCookie, HttpAuth). We also would like to have an option to release those low level components as separate jars. > 2) How does this balance with the Silk - Web Components subproject? > Where shall we draw the line between HTTP and Web? > I _personally_ believe it is all very simple. We are primarily concerned with the _transport_ aspects of HTTP. (1) We provide NO code of what so ever to produce or consume content enclosed in HTTP messages. (2) We have no plans to develop _application_ APIs based on HTTP competing with javax.servlet, for instance. Correct me if am wrong, Jakarta Silk is meant to support the reuse of common _application_ aspects. Cheers, Oleg > Hen [1] http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
