[
https://issues.apache.org/jira/browse/HTTPCLIENT-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908671#action_12908671
]
Oleg Kalnichevski commented on HTTPCLIENT-994:
----------------------------------------------
> 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)
There would be too way much protocol logic beyond simple parsing operations in
the HttpCacheEntry to my personal liking. RFCs do get superseded with updated
versions. You never know what might happen in the future. If HttpCacheEntry API
proves inflexible to meet new requirements, pretty much the entire caching API
will have to be deprecated.
> 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.
I am not sure I agree. HttpCacheEntry has no dependency on CacheValidityPolicy
of what so ever.
> But generally speaking, I think this is as simple as "why have two classes
> when one will do"?
Because you never know what might happen in the future. I have been maintaining
HttpClient for looooong 7 years and I have had numerous moments when I wished
some bits of code had never been made a part of public API.
If you remain unconvinced I'll commit the patch within a few days.
Oleg
> 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]
