The problem of not using the posted social data could be that app dev's would use low TTL's or show out-dated info when people change their nickname, profile pic, etc..
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 :) Cool, will be easy to reproduce in php, thanks for the info! -- Chris On Mon, Apr 13, 2009 at 7:17 PM, Adam Winer <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> wrote: > > > >> On Sun, Apr 12, 2009 at 5:19 AM, Chris Chabot <[email protected]> > 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 > >> > > >> > > >
