On Thu, Aug 28, 2008 at 12:18 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote:
> 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. AbstractHttpCache shouldn't be doing any rewriting at all. Fix that and the other problems go away. > > > --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. > > > > >
