On Mon, Jul 14, 2008 at 1:44 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> 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.
That and the supporting classes like ContentFetcherFactory =). This would be
cleaner if there were just 3 separate interfaces (HttpFetcher,
SignedFetcher, OAuthFetcher). We'll never eliminate the switching logic in
the make request handler or the preloader (or in the upcoming proxied
content handler), so we may as well embrace 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.
I agree -- but I think the notion of adding caching as a part of the chain
just makes things more complicated. I'd rather rewriting be done at the
gadget rendering and proxy layers rather than the http layer, and that
rewritten content was cached independently of http responses. There are many
types of "rewriting" that might take place in the long run (including Caja),
so we may as well have that rewriting happening in a standard place rather
than putting it all over the code. We actually already have this partially
implemented in GadgetRenderingTask.
>
>
> Cheers,
> Brian
>
