hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] HttpCore 4.1-beta1 release preview
Date Mon, 22 Mar 2010 14:02:10 GMT
On Sun, 2010-03-21 at 20:43 +0000, sebb wrote:
> On 21/03/2010, Oleg Kalnichevski <olegk@apache.org> wrote:
> > Folks
> >
> >  Please DO try to find a few minutes to review the release notes and release
> > packages for the coming HttpCore 4.1-beta1
> Since this is the last chance to change the API, I have been having a
> look at the visibility and mutability of fields.

Hi Sebastian

We cannot do that without breaking full binary compatibility with 4.0.x
releases. As much as I consider binary compatibility for non trivial
changes utterly pointless, I still think we should not break
compatibility without a good reason. All these classes are not meant to
be thread-safe, so mutability of instance variables is not really an

We have a few options how to proceed:

* deprecate those classes and create copies under a different name,
which we could restructure as we please. The trouble is that deprecation
of AbstractHttpEntity and AbstractHttpMessage will entail deprecation of
more than a dozen classes in HttpClient, which can be quite ugly.

* release next release as 5.0-BETA1

* wait until we have enough important changes for a solid point zero
release and break binary compatibility at that point.

I suggest we take the last option for now. 

> AbstractHttpEntity
> has 3 protected fields, however there are public getters/setters for
> all of the fields, so it seems to me that the fields should be
> private. That would allow synch. to be added later if necessary.
> HttpEntityWrapper
> - wrappedEntity should be final.
> AbstractHttpMessage
> - headerGroup should be final
> - params should be private
> BasicHttpProcessor
> requestInterceptors and responseInterceptors should be final
> Should also be private, otherwise subclasses can subvert the non-null condition
> >  Release notes:
> > http://people.apache.org/~olegk/httpcore-4.1-beta1-preview/RELEASE_NOTES.txt
> I did not quite understand the following sentence:
> "HttpCore based on
> classic (blocking) I/O model is expected to be 5% to 10% faster
> compared to previous releases. "
> Does this mean that previous releases were not based on the classic
> I/O model, and that changing to it has made the improvement?
> Or are these two independent facts:
> HttpCore is based on the classic (blocking) I/O model.
> This release is expected to be 5% to 10% faster than previous releases

Sorry I failed to articulate the idea properly. HttpCore comes in two
flavors: classic (blocking) I/O based and NIO based. Performance
improvements apply to the blocking components only. Please re-phrase the
statement as you see fit.

> >  Release packages:
> > http://people.apache.org/~olegk/httpcore-4.1-beta1-preview/
> DOAP probably does not belong in the source archive (or elsewhere).
> It's now 2010; Notice file needs updating.

I'll take care of that


> Otherwise looks OK.

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

View raw message