[
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.
