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. > 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-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
