[
https://issues.apache.org/jira/browse/HTTPCLIENT-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908482#action_12908482
]
Jonathan Moore commented on HTTPCLIENT-994:
-------------------------------------------
I can understand keeping state and protocol processing decoupled, which is why
we have a CachedResponseSuitabilityChecker instead of just saying
HttpCacheEntry#canYouBeUsedToSatisfy(HttpRequest req). In this case, the
methods that got moved to HttpCacheEntry are all essentially properties of a
cache entry; just as a Header can find its HeaderElements for you, now an
HttpCacheEntry can tell you its apparent age (a *defined* property in the RFC).
Whether the caching module actually decides to use the cache entry to satisfy a
request is outside of the scope of the HttpCacheEntry.
Generally, I think the main advantage here is a simplification of the
implementation: one fewer class to maintain or understand. In particular, an
HttpCacheEntry is a domain object, whereas a CacheValidityPolicy is a construct
of the implementation. In this case, there is little future flexibility lost
here, since all the calculations are explicitly defined by the RFC, and we
still have a place to make implementation-specific behavioral changes
(CachedResponseSuitabilityChecker); we don't need two such places.
Finally, I think the CacheValidityPolicy and HttpCacheEntry as they exist in
trunk now exhibit a few OO "code smells", namely that they are two separate
classes that are tightly coupled; there isn't anything you can do with a
CacheValidityPolicy without also having an HttpCacheEntry instance. Also, the
CacheValidityPolicy's state is pretty much just a single boolean; there's not
much state there, just code, which suggests that the code probably wants to be
moved towards the state it operates on (HttpCacheEntry).
But generally speaking, I think this is as simple as "why have two classes when
one will do"?
> cache does not allow client to override origin-specified freshness using
> max-stale
> ----------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-994
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-994
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Affects Versions: 4.1 Alpha2
> Reporter: Jonathan Moore
> Attachments: max-stale.patch
>
>
> According to the RFC, the default freshness lifetime is supposed to be the
> LEAST restrictive of that specified by the origin, the client, and the cache.
> Right now, a client can't use 'max-stale' to relax the freshness constraints
> to get a cache hit without validation occuring first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
