RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
Christopher, > this thread has gotten a bit out of hand now... As long as we manage behaving as mature people, I see no problem in talking things through > offensive, implying that we're doing something weird by using CVS HEAD > of HttpClient (which is totally normal at Jakarta). And your comment > about API compatibility sounded like you don't care very much about > preserving compatibility. I apologize if my response sounded harsh to you. Allow me to point out, though, the problems of maintaining 2.0 API compatibility have been discussed repeatedly on this mailing list before, and the decision has been taken BY THE HTTPCLIENT COMMUNITY AS EARLY AS FEBRUARY that maintaining 2.0 compatibility was not feasible due to limitations of the existing architecture. It was a very hard decision and it has not been taken lightly. I believe there was nothing that precluded you from taking part in that decision making process and influencing its outcome. But once the decision has been taken, I do find it a bit irresponsible, to come up with (what I see as) demands to change the course of HttpClient development that suits best your particular project. We have been very explicit about API compatibility issue MONTHS IN ADVANCE: there's a 2.0 branch which will provide you with FULL API compatibility, and you will have our full support migrating to 2.1 once is its APIs are frozen, but further development of HttpClient is not possible without limited API changes in the 2.1 branch. > There is a *huge* difference between "we should make all possible > efforts to keep API compatibility" (Michael) and "we will no longer be > able to provide API compatibility" (Oleg). And the difference might not > even be technical ;-) I have always been a bad guy of HttpClient community ;-) And will remain a bad guy as long people are not willing to listen to their counterparts' arguments Cheers Evil Comrade Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
My 2 cents. It is ALWAYS possible to maintain binary compatibility. The downside is that it is ugly and gets unmaintainable over time and it occasionally forces you to create new classes or methods where you would have liked to have reuse the old name. Such is life. An acceptable compromise is to maintain deprecated methods and classes for a release or two and then remove them. Ralph -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Sunday, July 06, 2003 2:33 PM To: Commons HttpClient Project Subject: RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAut henticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java Vincent, I have a feeling that you somehow suspect me of waking up this morning and thinking: "Geez, I feel like screwing up those HttpClient APIs. Wouldn't that be fun?". Believe me, I am not THAT bad Please allow me to copy verbatim the paragraph from the release plan that I wrote: -- Objective: The objective of the 2.1 release of HttpClient is to build upon the foundation laid with the previous release while addressing those architectural shortcomings and flaws identified during 2.0 development process. Several well known and much complained about problems could not be resolved without sacrificing API stability. The primary motivation behind the 2.1 is to fix those design limitations, breaking 2.0 API compatibility where absolutely unavoidable, while preserving overall compatibility with 2.0 use patterns. -- Cmon, what else am I supposed to say to make you beleive? And of course, it just goes without saying that each and every patch will be discussed on this mailing list and committed only if there are enough confidence that it satisfies the above stated criteria. You are welcome to dispute the merits of each individual API breakage, but just demanding 100% compatibility with 2.0 release no matter what will effectively halt further development of HttpClient. Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
Hi Oleg, > -Original Message- > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > Sent: 06 July 2003 23:02 > To: Vincent Massol > Subject: RE:cvscommit: jakarta- > commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticat or > .javaTestHttpState.javaTestHttps.java > TestMethodsExternalHost.javaTestWebappBasicAuth.java > > > > Hey, we're simply users, not developers of HttpClient! :-) > > > > Vincent, what is wrong with trying to influence the course of HttpClient > development when development plans are being publicly discussed, but not > after a decision has been taken? There is nothing that precludes you > from voicing your opinion on issues that are important for you. I'm sorry Oleg, but I can only follow so many projects and HttpClient is not one of them. I just discovered that HttpClient had broken an API when Gump signaled it to us this morning and I thank it for that! Chris sent an email to the commons-dev list mentioning that he'd like the HttpClient to try to preserve API compatibility and to evolve the API instead of breaking it. I have supported his comment and I totally agree with him. > > > > > > > > Please also advice me how to fix these bugs while retaining 2.0 API > > > compatibility: > > > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20089 > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729 > > > > I fear I am not able to help much as I'm not an HttpClient developer and > > I would need to dive in the code to give any help. That said, there are > > always ways to evolve an API by going through a deprecation mechanism. > > > > It is not a problem to mark a method as deprecated. The problem is to > keep deprecated stuff fully functional once the overall architecture has > undergone some significant changes. I do not see at as always feasible. > > In my humble opinion 2.0 API has been REALLY stretched to its very limit > and have done everything possible within the constraints of the existing > architecture. > > Guys, please try to see a bit beyond your own project and your own > interests. The same can be said the other way around: Guys please try to see a bit beyond your own project and your own interests. HttpClient is famous now and you have customers to support! :-) Preserving compatibility is not always easy and sometime even not possible. What I am just saying is that you should try to make all your possible to preserve it and only break it from time to time when there's no other solution. Then, it should be clearly marked and an easy path should be offered for your users. As Michael said, the best solution is probably to address each problem one by one and try to find the less disruptive solution. Thanks to Gump, it should be relatively easy to detect breakages. Thanks -Vincent > > Cheers > > Oleg > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
