hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
Date Sun, 06 Jul 2003 21:12:19 GMT
Hi Oleg,

> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> 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
> 



Mime
View raw message