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
issue.

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

Oleg

> Otherwise looks OK.



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


Mime
View raw message