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 > > >
