Eric, I think there will be enough folks on this mailing list how would prefer to have the redirect problem solved without breaking the API by a simple drop-in replacement. They may well argue that what they are doing is absolutely 'standard': just using redirects. Redirects should not be considered non-standard just because Slide happened not to be using them.
Please correct me if I am wrong, but I think it has been clearly agreed upon as early as February this year that the next version would not and <strong>could not</strong> be a drop in replacement for what has eventually become 2.0 APIs. If all it takes is a "point zero" release number - so be it. But then I would suggest to stop making hacks like out recent exception framework redesign compromise and carefully redesign the complete API, so it can finally be something that we all are comfortable with. I know I am repeating myself, but the whole point of this version was to give our existing users something that is very (but not completely API) compatible with 2.0 before we embark on a long endeavour of a compete API redesign that may last for many, many months Cheers Oleg On Mon, 2003-07-28 at 15:56, Eric Johnson wrote: > Oleg, > > It doesn't matter too much to me either way. I've sent an email to the > slide-dev group suggesting that they switch to the 2.0 branch, but no > action has been taken yet. > > Slide is an interesting test case, if only because it is representative > of how other clients are using HttpClient, at least that is my guess. > > Mind you, I'm not saying that we should hold back HttpClient just for > Slide! I agree with you 100% that we should fix critical design flaws. > On the other hand, the webdav extensions that Slide has use HttpClient > in a way that I think most on this list would consider "standard." To > allow the Slide extensions to continue to work in a "drop-in" manner > with both the 2.0 and 2.1 branch would be beneficial to all, and not > just the Slide project. > > Mike raised the version numbering issue a while back. A very simple, > clear-cut way for us to look at it is to say that if Slide DAV > extensions continue to work with both 2.0 and 2.1, then I think we can > get away with calling the changes that are in progress part of a 2.1 > release. Otherwise, we should be honest with the clients of HttpClient > and call it 3.0. > > That's just my perspective. > > Kalnichevski, Oleg wrote: > > >Eric, > > > >Of course, the patch can be rolled back. Alternatively we can leave > >getResponseContentLength() method as is, and introduce an additional method that > >serve similar function but returns long, not int. > > > > > I don't believe we should just roll back the patch either. It is a > design flaw that needs to be fixed. I suggested getResponseLength() as > the new alternative that returns a long. > > >But the whole point is that I really can't understand why Slide folks cannot just > >use stable 2.0 branch. At the end of the day back in February we decided to release > >2.0 with the sub-optimal API primarily in order to keep Slide folks happy (even > >though we were still formally in alpha phase). And now what? Is history about to > >repeat itself? > > > > > I don't think that history will repeat itself, because the 2.0 library > is a much more stable, reliable, and robust solution that can be built > on top of in a contrast to the way that many emails to this list have > suggested the 1.0 release was unstable, unreliable, slow, and error > prone. Slide has a fallback position now that it didn't have before. > > >Is there any particular reason for Slide to use CVS HEAD? > > > > > No. > > -Eric. > > > > > --------------------------------------------------------------------- > 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]
