On Mon, Jul 14, 2008 at 12:19 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> Coupling rewriting to http fetching further just makes the problem worse.
It has to be coupled somewhere. The question is what kind of coupling
is cleanest.
> There's really no reason why the only thing being cached has to be an
> HttpResponse, or, indeed, why there can't be multiple caches for different
> types of data.
Somewhere has to be aware of the semantics of the HTTP/1.1 caching
spec. AbstractHttpCache seems like a reasonable place for that logic.
The code below that can (should?) be reasonably independent of the
type of data being cached, modulo the kind of element driven expiry
abstraction that Ian proposed.
> Right now, the callers of the fetchers have to know a lot about every type
> of request. That calls for separate interfaces, not globbing more stuff into
> the same interface.
The caller of the fetcher has to know about the new interfaces. =)
There is no way to avoid something fairly close to MakeRequestHandler
having to know something about OAuth and signed fetch. I like the way
this was handled for oauth. MakeRequestHandler has very few OAuth
specific lines of code. There is:
case OAUTH:
return contentFetcherFactory.getOAuthFetcher(token, new
OAuthRequestParams(request));
And later:
// Merge in additional response data
for (Map.Entry<String, String> entry : results.getMetadata().entrySet()) {
resp.put(entry.getKey(), entry.getValue());
}
That's it. OAuthRequestParams handles the parsing of the various
OAuth related parameters to makeRequest, and the OAuth logic is
encapsulated in a content fetcher. The switch from opensocial 0.7 to
opensocial 0.8 OAuth syntax did not impact MakeRequestHandler at all.
That's the kind of independence we should shoot for.
What freaks me out about content-rewriting being munged in with
caching is that I've got *no idea* how the OAuth changes for caching
impact content rewriting. The interface to the cache is fuzzy, and
that makes it hard to reuse both the caching and the content rewriting
code.
Cheers,
Brian
