On Mon, Mar 24, 2008 at 5:54 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> Yes! > > Though unless you can come up with a use case for chains longer than > two handlers, I'm not inclined to support them. I don't really see how supporting 2 is any different from supporting N. > > On Mon, Mar 24, 2008 at 5:51 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: > > Can we insert a chain-of-responsibility pattern in here? It would be > nice > > to have several stacked handlers for incoming/outgong content... > > > > > > > > > > On 3/24/08 5:46 PM, "Kevin Brown" <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Mar 24, 2008 at 5:30 PM, Brian Eaton <[EMAIL PROTECTED]> > wrote: > > > > > >> A little while ago a patch I sent to shindig to implement signed > fetch > > >> got submitted. I'm looking at the full OAuth flow now, and I've > come > > >> to the conclusion that the interface I started to design for signed > > >> fetch is lame. Stupid. Sucky, even. > > >> > > >> I'd like to implement OAuth (and reimplement signed fetch) as > > >> interfaces of RemoteContentFetcher. A signing remote content > fetcher > > >> would sign a request, and then forward it to a real content fetcher > > >> for fulfillment. OAuth would be similar. > > >> > > >> Comments? > > > > > > > > > I agree that it's lame (as I mentioned in person on a few occasions, > I think > > > the whole security token / signing bits need to be revisited). > > > > > > Rather than making a separate fetcher, though, I think it would be > more > > > appropriate to do this: > > > > > > - Create a signing interface and oauth implementation of said signer > (hand > > > waving here) > > > - Pass the signer to RemoteContentFetcher.fetch() > > > > > > RemoteContentFetcher itself could use some work (specifically, it > should be > > > using commons HttpClient instead of the ad hoc stuff we've got today) > -- I'd > > > rather not require that anyone implementing a custom fetcher be > subjected to > > > having to implement two of them, though. > > > > > > > > > > > -- ~Kevin
