As I was thinking about this, I realized that the simplest solution lies in removing the extra cruft by just adding authz and security token parameters to ContentFetcher.fetch. This call can then delegate to the appropriate implementations of OAuth, signed fetch, or plain fetch.
I think it's inevitable that future changes in the spec will require authz support for more http request variants, so this would probably be useful for the future as well. Thoughts? On Mon, Apr 28, 2008 at 12:57 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 12:32 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > Primarily readability, maintainability (hahahah...), and ease of > extending / > > modifying. I've been able to force it to working for the google > > implementation, but it's ugly as sin and relies on several unnecessary > > workarounds. > > The single most painful piece of the authentication work was the > necessity of modifying ProxyHandler. If you're optimizing for > maintainability, I'd vote for hooks making customization in that code > simpler. I think that same change would make the caching changes more > readable as well. > > > I didn't realize that OAuthFetcher was completely broken. I thought it > was > > just "mostly broken" :). > > Nah, it's hosed, throws a null pointer exception as soon as you try to > use it. Somebody (probably me or louis) needs to update it to work > with the new mechanism for returning metadata to ProxyHandler. The > change should be simple. > > Plus there should be test cases to catch that kind of regression. > That's definitely up to me, I suspect. > > Cheers, > Brian >
