On Tue, 2014-10-21 at 08:51 -0400, Karl Wright wrote: > Hi Oleg, > > Will there be a 4.x release that will deal with RFC 7230? > > I am wondering why you propose breaking backwards compatibility at the same > time you propose adding major new functionality.
I think it was proposed more than three months ago. If RFC 7230 related changes turn out to be minor there is nothing that stops us from porting them to 4.4. But I doubt it is going to be the case. > I've looked at the RFC > and don't offhand see any reason why this should be related. We've just > gone through a rather painful API HttpClient upgrade process in ManifoldCF, > and we have several component libraries (e.g. SolrJ) who haven't even > gotten fully to the "builder" model yet. By tying together new > functionality with a brand-new API, essentially everyone has to start over > only a few months after the last update was complete. > APIs of blocking I/O components is unlikely to change much. NIO side of things is more likely to change. Moreover, it will take a considerable while before 5.0 supersedes 4.4 as a stable GA release. There should be enough time for downstream projects to adapt. Oleg > Maybe I'm in the minority, but when I wind up spending 30% of my > development time on HttpClient updates, I consider that a problem. > > Karl > > > On Tue, Oct 21, 2014 at 8:14 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > > > Folks > > > > HttpCore trunk is now 5.0-alpha1. The main focus of 5.0 is compliance > > with RFC 7230 and related RFCs. However this is a point when we can > > revisit design decisions, re-do things that need to be re-done and > > improve things that need to be improved without constraints of API > > compatibility. > > > > (1) Do we want to make anther attempt at making HTTP message objects > > immutable? > > > > (2) Do we want to consider using a 3rd party I/O (NIO) framework instead > > of maintaining our own? > > > > (3) HttpCore presently does not rely on any logging toolkits or APIs. It > > always propagates exceptions to the caller and let the caller handle > > them. There are circumstances though when one might want to log certain > > debug info or contextual details. > > > > (4) Anything else one deems important. > > > > I'll be mostly removing deprecated code and cleaning up cruft in > > non-deprecated code for some while. Anyone is more than welcome to join > > in and work on some other things. > > > > Oleg > > > > > > > > > > --------------------------------------------------------------------- > > 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
