hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <mbe...@gmail.com>
Subject Jakarta HttpXXX Charter, was: Important things to discuss. Please make your opinion known
Date Sun, 28 Aug 2005 21:25:45 GMT
Now that we've gotten the ball rolling, let's try to focus a little
more on HttpClient's charter as we move to Jakarta level.  This is the
document that will define our goals, name, and what exactly is or
isn't in bounds as far as development goes.

I'll get things started with my preferences, some of which have been
taken from others' posts:

 - Build a set of smallish reusable HTTP components, call it Http
Components perhaps
 - Use these component to create a few higher level products like an
HTTP client, named HttpClient for example :)  Perhaps create a few
other things in conjunction with other groups like a Coyote Connector
(Tomcat), a simple test HTTP server (Axis),  a web crawler (someone). 
The key here would be to leverage the components and team up with
other projects to reduce the duplication of effort that currently
exists.
 - Any new large HTTP related projects that come up and are not being
developed in conjunction with other groups should be spun off, either
as new Jakarta, Sourceforce, or other projects.

Everyone please feel free to post your ideas and suggestions.

Thanks,

Mike

On 8/28/05, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sat, 2005-08-27 at 20:37 -0400, Henri Yandell wrote:
> > On 8/26/05, Oleg Kalnichevski <olegk@apache.org> 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: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message