[
https://issues.apache.org/jira/browse/HTTPCLIENT-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034033#comment-13034033
]
Jon Moore commented on HTTPCLIENT-1090:
---------------------------------------
Actually, I'm inclined, but I think Oleg has a point about having time to do
it. :)
That said, this is something I've been thinking about, and I think the rough
approach David outlined is probably right. I think roughly this is a caching
layer on top of the CachingHttpClient with a slightly different interface. I
think the easiest approach is to have this layer cache parsed object bodies
along with origin response headers, then apply some of the same logic from the
guts of CachingHttpClient to determine whether the parsed object can be
returned as-is, or if revalidation is required. There's a bit of trickiness
here, because I think maintaining the semantic transparency of HTTP caching is
important, and we'd want to make sure that cached objects could be invalidated
by POSTs to the appropriate URL, for example.
> CachingHttpClient should be able to cache ResponseHandler responses (or the
> result of some new form of ResponseHandler)
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1090
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1090
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.1.1
> Environment: Mac OS X 10.6.7 + Eclipse Helios SR2
> Reporter: David Waite
> Priority: Minor
> Fix For: Future
>
>
> When creating a ResponseHandler to parse the response value into a usable
> java object, I notice that the code is executed every time, even if the
> response object is served from cache. It would be nice to have a system where
> a ResponseHandler can be written such that its value is also served from
> cache. This may require a different interface which:
> - Exposes just the values which are not altered when served from a cache
> - Returns objects which can be cached out of process ( through documentation,
> and having the return type extend Serializable)
> Alternatively, if there is a header uniquely identifying a response, a
> WeakHashMap could be used to provide a cache associating a response with a
> created object (although such a cache would not correlate to the HTTP cache
> in terms of retention)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
