The TTL is defined by the HTTP response headers from the proxied server. Instead of using TTL to deal with updates like appdata, etc., we rely on the invalidation spec; canvas views can explicitly request invalidation of the current viewer's content, which will flush the profile, canvas, etc. views with one call.
On Mon, Apr 13, 2009 at 10:12 AM, Chris Chabot <chab...@google.com> wrote: > Profile details probably won't change to often, but appdata and activities > might. So your caching with a configurable & low TTL I presume? > > > On Mon, Apr 13, 2009 at 6:49 PM, Adam Winer <awi...@google.com> wrote: > >> On Sun, Apr 12, 2009 at 5:19 AM, Chris Chabot <chab...@google.com> wrote: >> > Hey All, >> > >> > Proxied content and data pipelining is pretty much done in php-shindig, >> and >> > the fetching & posting behind it works according to the normal http spec, >> > get's are cached, post's are not. However data pipeling does mean all the >> > requests to the app's back-end are posts, so not cached. >> > >> > Has anyone looked at the possibility of caching those requests too (most >> > likely strategy would probably be to use the request url + post body as >> > cache key) for java shindig? >> >> The Java implementation does cache, intentionally not using the post >> body as a cache key. As protection for data leakage, requests for >> viewer or owner data require that the request be signed by viewer or >> by owner (and signing is part of the cache key). >> >> -- Adam >> >> >> > >> > I'm wondering if the trade-off of the resources it would cost would be >> worth >> > it from the save-the-gadget-devs-server point of view. >> > >> > Any thoughts? >> > >> > -- Chris >> > >> >
