hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: Http components to Network components ?
Date Wed, 15 Mar 2006 08:57:38 GMT
Hi Ryan,

> And all the code that is common to smtp, http, ftp, irc, etc.... could
> go in the commons-net layer.
> [...] to avoid code/method duplication
> across various projects all working on the same issues......  like if
> the httpComponenets project
> improves socket timeout handeling (or some other basic network layer
> advantage), it would be nice if all the protocols were able to benefit
> from the new code, not just http components.

We are very much trying to stay away from basic network layer stuff.
We have to create sockets and secure sockets, so we defined interfaces
with default implementations - just to isolate the network layer.
The default implementations rely on standard JDK APIs.

Also, one of the primary targets of the http-core component was to
avoid any external dependencies.

If we had Jakarta Network Components with a basic network layer, we
would provide another, non-default implementation for the above
mentioned interfaces which would be based on the new network layer.
Speaking from an HttpComponents perspective, that means more code
instead of less duplication.

There is some potential for generalizing things. A network layer is
one example: SSL/TLS and SOCKS support for all network components.
The HttpParams stuff is another example, or maybe commons-net has
their own parameter framework which we'd have to merge.
But generalizing and changing all network components to use the new
APIs is a lot of work and even more discussion. Currently, Oleg is
doing almost all the coding on HttpComponents and all on HttpClient,
and I'm helping him a little with HttpComponents. Others are providing
valuable feedback, reviews and suggestions, but they are not driving
development. The two of us are not enough to come up with a complete
HttpComponents in the near future, let alone to take over even more
code that needs refactoring.
Unless a whole bunch of active developers are moving over with the
code, I am very much in disfavor of a change that would in essence
mean generating plenty of work nobody will be doing.


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

View raw message