Thanks for taking a look Pan. I will post a proposed revision to the spec based on this work soon.
http://codereview.appspot.com/23041/diff/3023/2032 File java/gadgets/src/main/java/org/apache/shindig/gadgets/http/DefaultInvalidationService.java (right): http://codereview.appspot.com/23041/diff/3023/2032#newcode71 Line 71: public void invalidateApplicationResources(Set<Uri> uris, SecurityToken token) { On 2009/03/04 05:54:27, panjie.pan wrote:
(Collection<Url> uris, SecurityToken token) should be enough.
Logically its a set, no need to be less specific. http://codereview.appspot.com/23041/diff/3023/2032#newcode74 Line 74: httpCache.removeResponse(new HttpRequest(uri)); On 2009/03/04 05:54:27, panjie.pan wrote:
I think we should mark response as invalid response rather than remove
it. So
that we can serve stale response when backend is unavailable.
Given that this is for specs and message bundles which have their own post-parse caches this should be fine. If an app decides to flush itself it had better make sure the replacement is available. http://codereview.appspot.com/23041/diff/3023/2032#newcode83 Line 83: */ On 2009/03/04 05:54:27, panjie.pan wrote:
To invalidate a user will invalidate all request/response whose
owner/viewer is
the user. Shall we separate owner from viewer?
Thats actually what happens, take a look at how we add the marks to the HttpResponses prior to caching them. A response fetched signed by viewer only requires the mark for the viewer to match, a response fetched signed by owner only requires to owner mark to match, a response fetched signed by both requires both marks to match. http://codereview.appspot.com/23041/diff/3023/2040 File java/gadgets/src/main/java/org/apache/shindig/gadgets/http/DefaultRequestPipeline.java (right): http://codereview.appspot.com/23041/diff/3023/2040#newcode92 Line 92: if (!request.getIgnoreCache()) { On 2009/03/04 05:54:27, panjie.pan wrote:
If fetchedResponse.isError(), we will cache an error response.
Yes, largely to avoid generating excessive traffic to a backend which is repeatedly failing. This has been the behavior for quite a while. error responses have a much shorter TTL in the cache however. http://codereview.appspot.com/23041/diff/3023/2027 File java/gadgets/src/main/java/org/apache/shindig/gadgets/http/InvalidationHandler.java (right): http://codereview.appspot.com/23041/diff/3023/2027#newcode72 Line 72: // Assume the the viewer content is being invalidated if it is available On 2009/03/04 05:54:27, panjie.pan wrote:
Why we need to invalidate viewer by default?
This is a convenience when making the call from inside a running gadget. http://codereview.appspot.com/23041
