Re: HC 5.0 scope and design decisions

I created an HttpCore ticket to get started: https://issues.apache.org/jira/browse/HTTPCORE-436 I can do the port for Core and the other components if the community agrees that it is a good thing. Gary On Fri, Sep 30, 2016 at 2:50 PM, Gary Gregory wrote: > > > On Fri,

Re: HC 5.0 scope and design decisions

On Fri, Sep 30, 2016 at 1:15 AM, Julian Sedding wrote: > Hi all > > I am not familiar with log4j2, but have used slf4j extensively over > the last years. > > As I understand log4j2 clearly separates its API from the > implementation. If this is true, are there any major

Re: HC 5.0 scope and design decisions

Hi all I am not familiar with log4j2, but have used slf4j extensively over the last years. As I understand log4j2 clearly separates its API from the implementation. If this is true, are there any major benefits to using the log4j2 API over the slf4j API? If this is not the case, and the

Re: HC 5.0 scope and design decisions

On Thu, 2016-09-29 at 09:27 +0530, Asankha C. Perera wrote: > Hi Oleg ... > > Should be remain faithful to Commons Logging or shall we finally migrate > > to SLF4J? > I agree with Gary that Log4J2 is better than SLF4J too. Since we also > have Gary's experience and support to move to it, I

Re: HC 5.0 scope and design decisions

Hi Oleg The HTTP/2 transport in trunk has been shaping up reasonably well. I have made some good progress recently and am cautiously optimistic that there should be a HttpCore 5.0 alpha release with the new non-blocking HTTP/1.1 and HTTP/2 transports within a month or two. HttpClient 5.0 alpha

Re: HC 5.0 scope and design decisions

On Wed, 2016-09-28 at 22:28 +0300, Dmitry Potapov wrote: > ... > > > > Damn. I had no idea you were working on something like that. I am > > currently in the process of re-writing the old HTTP/1.1 non-blocking > > transport to re-align it with the new HTTP/2 code. I just wrote a > > completely

Re: HC 5.0 scope and design decisions

> On 28 Sep 2016, at 22:21, Oleg Kalnichevski wrote: > >> On Wed, 2016-09-28 at 21:48 +0300, Dmitry Potapov wrote: >>> On Wed, Sep 28, 2016 at 07:53:52PM +0200, Oleg Kalnichevski wrote: On Wed, 2016-09-28 at 18:40 +0300, Dmitry Potapov wrote: Oleg, >>> >>> Hi

Re: HC 5.0 scope and design decisions

On Wed, 2016-09-28 at 21:48 +0300, Dmitry Potapov wrote: > On Wed, Sep 28, 2016 at 07:53:52PM +0200, Oleg Kalnichevski wrote: > > On Wed, 2016-09-28 at 18:40 +0300, Dmitry Potapov wrote: > > > Oleg, > > > > > > > Hi Dmitry > > > > > I'm not sure I got it right. > > > Are you going to drop

Re: HC 5.0 scope and design decisions

On Wed, Sep 28, 2016 at 07:53:52PM +0200, Oleg Kalnichevski wrote: > On Wed, 2016-09-28 at 18:40 +0300, Dmitry Potapov wrote: > > Oleg, > > > > Hi Dmitry > > > I'm not sure I got it right. > > Are you going to drop org.apache.http.protocol.HttpService class? > > Yes, I do. > > > For now it is

Re: HC 5.0 scope and design decisions

On Wed, 2016-09-28 at 20:16 +0200, Julian Reschke wrote: > On 2016-09-28 19:53, Oleg Kalnichevski wrote: > > ... > >> 2. Compless/decomplress requests and responses on the fly > >> (DecompressingEntity really does the job for servers). This is possible > >> for NIO too, but will require to

Re: HC 5.0 scope and design decisions

On 2016-09-28 19:53, Oleg Kalnichevski wrote: ... 2. Compless/decomplress requests and responses on the fly (DecompressingEntity really does the job for servers). This is possible for NIO too, but will require to implement non-blocking analog for GzipInputStream. Very true. However we

Re: HC 5.0 scope and design decisions

On Wed, 2016-09-28 at 18:40 +0300, Dmitry Potapov wrote: > Oleg, > Hi Dmitry > I'm not sure I got it right. > Are you going to drop org.apache.http.protocol.HttpService class? Yes, I do. > For now it is the only way to: > 1. Process full-duplex requests (i.e. start sending reply before

Re: HC 5.0 scope and design decisions

Oleg, I'm not sure I got it right. Are you going to drop org.apache.http.protocol.HttpService class? For now it is the only way to: 1. Process full-duplex requests (i.e. start sending reply before complete request entity consumption) 2. Compless/decomplress requests and responses on the fly

Re: HC 5.0 scope and design decisions

I think it is probably fine to go with a single style of I/O for the lower layer transport; if we want to also provide a blocking interface I think it would be ok to write that as an adapter up at the HttpClient level. On the Java 8 side, I think a major release (5.x) that generally has API

Re: HC 5.0 scope and design decisions

Starting to move to Java 8 is a nice idea. Let's do it. I could see all 5.0 components being Java 8. Gary On Sep 28, 2016 7:39 AM, "Oleg Kalnichevski" wrote: > Folks > > The HTTP/2 transport in trunk has been shaping up reasonably well. I > have made some good progress

Re: HC 5.0 scope and design decisions

Log4j 2 is so much better than anything else out there. I'm biased as I am on the Logging PMC. I can do the conversion, just say when. Gary On Sep 28, 2016 7:39 AM, "Oleg Kalnichevski" wrote: > Folks > > The HTTP/2 transport in trunk has been shaping up reasonably well. I >

HC 5.0 scope and design decisions

Folks The HTTP/2 transport in trunk has been shaping up reasonably well. I have made some good progress recently and am cautiously optimistic that there should be a HttpCore 5.0 alpha release with the new non-blocking HTTP/1.1 and HTTP/2 transports within a month or two. HttpClient 5.0 alpha