On Mon, 2010-03-22 at 22:56 +0000, sebb wrote: > 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. > > > >
Folks, I updated the release notes and the preview packages based on your feedback. Feel free to double-check. http://people.apache.org/~olegk/httpcore-4.1-beta1-preview/ I will start cutting official release packages tomorrow or the day after tomorrow. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
