On Mon, Apr 13, 2009 at 10:43 AM, Chris Chabot <[email protected]> wrote: > Ah so my hope that the oauth_body_hash would in essence invalidate the > cached content when the social data changes is invalid?
Moreover, we don't even perform the data pipeline fetch if the content is available in the cache - so there's no way to check a body hash even if we wanted to. This is all for the best, since we don't want to require pipeline execution for all renders. (Pipelining plus templating always has to do the fetches, which makes it less efficient.) > Is this perceived as a possible problem (stale social data when updated > outside of the app's knowledge) or are we just not to worried about it? It's a possible problem, and we're not too worried about it (yet). > > -- Chris > > On Mon, Apr 13, 2009 at 7:39 PM, Brian Eaton <[email protected]> wrote: > >> On Mon, Apr 13, 2009 at 10:35 AM, Chris Chabot <[email protected]> wrote: >> > However I just realized that the oauth_body_hash is part of the request >> URL >> > so actually part of the cache key.. so the social post data *is* actually >> > used already in java from what you described :) >> >> Java shindig puts caching in the pipeline before OAuth, to avoid >> having the OAuth timestamp parameters constantly bust the cache. >> >
