On 22/03/2010, Oleg Kalnichevski <ol...@apache.org> wrote: > On Sun, 2010-03-21 at 20:43 +0000, sebb wrote: > > On 21/03/2010, Oleg Kalnichevski <ol...@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.
OK. I was considering 4.1 in isolation. I'll create at JIRA with patches to record the proposals. > > > 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. > Your last change has fixed the ambiguity very well. > > > > 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-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
