incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <>
Subject Re: HttpClient, HttpComponents (was Jakarta)
Date Fri, 12 Oct 2007 19:56:20 GMT
Hi Steve, Niclas,

>>> Any Java stack that does SOAP or REST should be using
>>> HttpClient
>> That seems to indicate that it should be a TLP in its own right.
> you want that, you get my support.

Thanks for your encouragement. I'm currently drowned in work,
but I intend to kick off the (hopefully last) TLP discussion
on httpcomponents-dev@jakarta before the end of this month.
Unless Oleg beats me to it :-)

> axis, ant-contrib, maven, jetty, wss4j, groovy. So not xerces or xalan.
> Maybe they are hoping someone will fix now it
> is OSS/

Xerces and Xalan have plug-in interfaces for resolving external
references. They wouldn't do themselves a favour by adding an
external dependency for the default implementation. Just as we
wouldn't do ourselves a favour by shipping HttpComponents with
a specific SSL implementation.

>> And if the charter is extended to http server side as well (without
>> the servlet cruft ;o) ), we have a pretty immense project.

That already happened when HttpComponents left Commons
to become a separate Jakarta sub-project two years ago:

HttpComponents Core is agnostic, while HttpComponents Client is
the future replacement for the client-side 3.x codebase we'd like
to bury. The charter also includes specific statements that we will
not be developing server-side application layer APIs. I believe that
was necessary because others developing server-side HTTP (Tomcat?)
felt that we were stepping on their toes. At the time, it was
Apache policy to not allow competing projects, or so I've heard.

Your help to define the scope for the new project will be most

> I'd keep server side separate, but a rest-centric server side stack
> (with no attempts to support WSDL) would be appealing, though restlets
> exist for that purpose.

Hmm. Can't say that I've ever perceived REST as much more than a
buzzword, but you're welcome to share your ideas. Even more so if
you bring in some folks who want to contribute code ;-) The current
developers are maxed out with pushing the two components we've got
towards production quality.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message