hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Moore (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-994) cache does not allow client to override origin-specified freshness using max-stale
Date Sun, 12 Sep 2010 15:36:33 GMT

    [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message