hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r1571715
Date Mon, 03 Mar 2014 18:57:05 GMT
On 3 March 2014 10:43, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sun, 2014-03-02 at 01:24 +0000, sebb wrote:
>> On 26 February 2014 14:03, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Tue, 2014-02-25 at 19:07 +0000, sebb wrote:
>> >> On 25 February 2014 14:46,  <olegk@apache.org> wrote:
>> >> > Author: olegk
>> >> > Date: Tue Feb 25 14:46:07 2014
>> >> > New Revision: 1571715
>> >> >
>> >> > URL: http://svn.apache.org/r1571715
>> >> > Log:
>> >> > Made AsynchronousValidationRequest public
>> >>
>> >> Should this be applied to 4.3.x as well?
>> >>
>> >> I'm happy to do it if so.
>> >>
>> >
>> > I am not sure. I generally avoid adding new classes and methods in
>> > stable branches. I would just leave 4.3.x as it is, but we will not
>> > stand in your way if you decide otherwise.
>>
>> AFAICT it's not possible at present for anyone to create a
>> SchedulingStrategy unless the class is in the same package as
>> AsynchronousValidationRequest.
>>
>> It's not possible to implement the required interface method:
>>
>> void schedule(AsynchronousValidationRequest revalidationRequest);
>>
>> without having access to the AsynchronousValidationRequest class which
>> is currently package protected.
>>
>> So I think the class must be made public unless there is no intention
>> to allow users to provide their own SchedulingStrategy.
>>
>> I don't know which of its fields are likely to be needed by the
>> schedule() method apart from consecutiveFailedAttempts which already
>> has a public getter.
>> The trunk version now has a public getter for the identifier; for
>> consistency perhaps that should also be added to 4.3.x?
>>
>>
>
> HttpClient 4.3 ships with two public implementations of this interface.
> Those classes are likely to be enough for the majority of users. I would
> rather not make any API changes to the stable branch unless absolutely
> necessary.

In which case, I think the Javadoc needs to be updated to note this.

However, I just don't understand the rigid stance on API immutability.
Yes, changes should be carefully reviewed to ensure that they make sense.
But in this case the next release has already made the proposed change.
And backwards compatibility is very unlikely to be an issue.

> 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
View raw message