I think we're largely in agreement, then, but are out of alignment by a matter of degrees.
Rather than removing classes right away, I'd like to see them deprecated for at least one major release. That leaves clients with the "crumbs" that they can follow to migrate their code, rather than discovering that their code is completely broken and must be rewritten. So I would say that we cannot *dump* the HttpMethod interface just yet.
As a separate design issue, I don't think HttpMethodBase *should* be considered the "base" from which all methods must inherit. It simply does way too much, so I think there needs to be an intermediate class, which I would call AbstractHttpMethod.
-Eric.
Kalnichevski, Oleg wrote:
Eric,
I find it hard to disagree with you, being a fan of incremental, iterative development myself. I just regret all the energy and time that went into 2.0 API compatibility workarounds so far. If we go with 3.0 then I would like to see a few more 2.0 API breakages that had been turned down for the sake of maintaining 2.0 compatibility, especially in the exception handling framework. I would also suggest HttpMethod interface be completely gotten rid of and the abstract HttpMethodBase renamed to HttpMethod.
Oleg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
