I see fixing the rewriter's interface as largely orthogonal to the problem of caching rewritten content. One way or another, the rewriter takes input and generates output -- the output needs to be cached, and that's what this approach does. The described approach is designed simply to bracket the amount of logic owned by each class. BasicContentRewriterRegistry registers and rewrites; CachingContentReweriterRegistry adds a caching layer atop that. Per the previous thread, CachingWebRetrievalFactory is a detail I'm willing to remove in favor of putting *most* caching logic in a TtlCache wrapper. That would simplify CachingContentRewriterRegistry in that it could subclass BasicCRR. Q: In an earlier thread you'd suggested adding another cache, but here you suggest that "delegating to a shared cache" is better. Perhaps I'm confused, but isn't a shared cache still possible here, depending on the implementation of CacheProvider?
Perhaps you're referring to a shared cache between rewritten gadget content and rewritten makeRequest content -- on this note, I completely agree. I'm just trying to find an incremental step that maintains rewritten gadget content caching. As indicated in other threads, AbstractHttpCache (rewritten makeRequest cache) needs to be significantly cleaned up. At that time, consolidation with this rewritten cache should occur. --John On Wed, Aug 27, 2008 at 9:54 PM, Kevin Brown (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SHINDIG-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626426#action_12626426] > > Kevin Brown commented on SHINDIG-500: > ------------------------------------- > > I think that's spending entirely too much effort to avoid fixing the > simpler problem, which is that the rewriter has a bad interface. > > Far fewer people are going to be affected by fixing the rewriter's > interface than are going to be affected by mucking around with the spec > factories. The new code is incredibly difficult to follow, and will > inevitably lead to bugs. > > Using CachingWebRetrievalFactory to cache rewritten content is an even > worse idea, because it means using an in-memory LRU cache for caching > rewritten content that would normally be delegated to a shared cache, > forcing users to write painful deserialization routines. > > The cache for rewritten data needs to look something like > > Cache<CacheKey, CachedData> > > Where CacheKey is similar to the cache keys used for caching HTTP requests > currently, and CachedData is pretty much just a String at this point in > time. > > Rewriting gadget specs is only one small part of rewriting. In many ways, > it's the less critical part as developers make such heavy use of makeRequest > and (soon) proxied content. > > > Make Gadget Object's content that of the active View > > ---------------------------------------------------- > > > > Key: SHINDIG-500 > > URL: https://issues.apache.org/jira/browse/SHINDIG-500 > > Project: Shindig > > Issue Type: Sub-task > > Components: Gadget Rendering Server (Java) > > Reporter: John Hjelmstad > > Assignee: John Hjelmstad > > Attachments: spec-immutable-notdoneyet.patch > > > > > > Step #1 of > http://mail-archives.apache.org/mod_mbox/incubator-shindig-dev/200808.mbox/[EMAIL > PROTECTED] > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
