You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2014/10/21 14:14:31 UTC
HttpCore trunk is now 5.0
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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HttpCore trunk is now 5.0
Posted by Gary Gregory <ga...@gmail.com>.
At the language level, I wonder how better served the code would be by
using try-with-resources.
Gary
On Wed, Oct 22, 2014 at 9:56 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2014-10-22 at 01:10 -0400, Gary Gregory wrote:
> > How about bumping to Java 7?
> >
>
> Personally I would be in favor of upgrading to Java 7, but would not
> rush it until we actually need Java 7 features like concurrent Deque.
>
> Oleg
>
> > Gary
> >
> > 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-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: HttpCore trunk is now 5.0
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2014-10-22 at 01:10 -0400, Gary Gregory wrote:
> How about bumping to Java 7?
>
Personally I would be in favor of upgrading to Java 7, but would not
rush it until we actually need Java 7 features like concurrent Deque.
Oleg
> Gary
>
> 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-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HttpCore trunk is now 5.0
Posted by Gary Gregory <ga...@gmail.com>.
How about bumping to Java 7?
Gary
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-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: HttpCore trunk is now 5.0
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2014-10-21 at 09:56 -0400, Karl Wright wrote:
> bq. I think it was proposed more than three months ago.
>
> Well, three months ago I was in the midst of a major release cycle, so I'm
> not surprised I missed it go by.
>
> bq. 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.
>
> Out of curiosity, what RFC 7230 functionality do you see as invalidating
> current NIO APIs?
>
This is not really RFC 7230 related but is simply due to a greater
complexity of asynchronous i/o in general. API changes in HttpCore NIO
may be driven by changes in the i/o reactor components.
> bq. 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.
>
> Depends on the project, of course. Some projects (like Solr for instance)
> seem to have very poor ability to adapt to changes. I can understand why
> because in ManifoldCF it takes us considerable effort (and some user bugs)
> to adapt every time APIs change. I don't mind API's changing but I really
> don't want to be *forced* to change simply because of new functionality,
> unless the new functionality is directly incompatible with the old APIs.
>
...
Every time I have to upgrade Lucene I usually wish very violent troubles
to all Lucene developers. Later I still decide that I love Lucene and
all Lucene developers
...
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HttpCore trunk is now 5.0
Posted by Karl Wright <da...@gmail.com>.
bq. I think it was proposed more than three months ago.
Well, three months ago I was in the midst of a major release cycle, so I'm
not surprised I missed it go by.
bq. 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.
Out of curiosity, what RFC 7230 functionality do you see as invalidating
current NIO APIs?
bq. 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.
Depends on the project, of course. Some projects (like Solr for instance)
seem to have very poor ability to adapt to changes. I can understand why
because in ManifoldCF it takes us considerable effort (and some user bugs)
to adapt every time APIs change. I don't mind API's changing but I really
don't want to be *forced* to change simply because of new functionality,
unless the new functionality is directly incompatible with the old APIs.
I've made my point, I think. FWIW, we "solved" this in ManifoldCF by
making major releases do *nothing* more to the API than remove deprecated
functionality. New API functionality is thus always cross-version, until
we explicitly stop supporting older major versions.
Karl
On Tue, Oct 21, 2014 at 9:37 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> 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-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: HttpCore trunk is now 5.0
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HttpCore trunk is now 5.0
Posted by Karl Wright <da...@gmail.com>.
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'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.
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-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: HttpCore trunk is now 5.0
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2014-10-21 at 09:49 -0400, Gary Gregory wrote:
> 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?
> >
>
> Like... Netty or Mina? Or some Jetty guts?
>
I dislike Netty and find JBoss XNIO much closer to how HttpCore NIO
framework operates but we can discuss all options.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HttpCore trunk is now 5.0
Posted by Gary Gregory <ga...@gmail.com>.
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?
>
Like... Netty or Mina? Or some Jetty guts?
Gary
>
> (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-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory