> 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.
Eric, There's one thing I REALLY dislike about this idea is that deprecation of HttpMethod interface will cause hundreds of deprecation warnings, which I personally find irritating. Please for the sake of my sanity, as I deal with HttpClient on a daily basis, if this is to be done, than it should be done as late in the process as possible. > 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. I am afraid I am not quite getting the point here. An intermediate class between what? Should AbstractHttpMethod implement HttpMethod and HttpMethodBase extend AbstractHttpMethod? Is that what you are saying? Which parts of the present HttpMethodBase code should be moved into AbstractHttpMethod and what should remain in HttpMethodBase? Frankly I do not think I see a lot of benefits in doing so. The concept of a method as an entity that combines HTTP request and HTTP response is fundamentally flawed. It should rather be completely done away with or left alone, IMO. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
