hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: HttpCore trunk is now 5.0
Date Tue, 21 Oct 2014 13:56:28 GMT
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 <olegk@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 <olegk@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message