I would suggest a controllable/Configurable ETag than Cache-Control, would you not Ikai?
-Sarath http://blog.sarathonline.com On May 5, 5:21 pm, "Ikai L (Google)" <[email protected]> wrote: > Sounds like a great idea. I agree with you. The problem with setting a cache > header is that you have very little control over expiration. The nice thing > about a cache that you handle at the filter level and in Memcache is that if > you can regenerate the keys, you can flush the thing (or you can flush > everything if need be). > > > > On Tue, May 4, 2010 at 4:45 PM, Sergio Lopes <[email protected]> wrote: > > Thanks for your answers! > > > The Cache-control idea is a good one, I think I'll try something here. > > But maybe it's a good idea to have some kind of server cache too. > > > Ehcache Web Module has a nice Java Filter that threats many corner > > cases (headers, gzip, ...). The only problem is that it's too coupled > > to Ehcache. I think I'll try to fork that project to use their Filter > > with AppEngine's memcache :) > > > On May 4, 6:22 am, Nacho Coloma <[email protected]> wrote: > > > Hi Sergio, > > > > > I'm thinking in a Filter that put page results in memcache when first > > > > accessed, and then getting that result in former accesses. > > > > That should work. All page cache implementations do more or less the > > > same. > > > > > The idea is simple but the implementation is not. (how to get the > > > > first request response? how to implement proper header management in > > > > that filter? how to not disable gzip using this?) > > > > * If there is content in memcache, you can deliver it and exit. > > > Otherwise, let the request proceed, and store in the cache. > > > * Be sure to set the cache timeout and calculate the cache key > > > correctly (e.g. include the user ID or the user locale if the cached > > > contents depend on that). > > > * For HTTP headers, this presentation may help: > >http://www.slideshare.net/icoloma/caching-web-contents-in-the-browser... > > > > It's more or less the same with JSP page fragments (except the > > > headers, of course). No rocket science. > > > > Cheers, > > > > Nacho. > > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Google App Engine for Java" group. > > > To post to this group, send email to > > [email protected]. > > > To unsubscribe from this group, send email to > > [email protected]<google-appengine-java%[email protected]> > > . > > > For more options, visit this group athttp:// > > groups.google.com/group/google-appengine-java?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine for Java" group. > > To post to this group, send email to > > [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<google-appengine-java%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine-java?hl=en. > > -- > Ikai Lan > Developer Relations, Google App Engine > Twitter:http://twitter.com/ikai > Delicious:http://delicious.com/ikailan > > ---------------- > Google App Engine links: > Blog:http://googleappengine.blogspot.com > Twitter:http://twitter.com/app_engine > Reddit:http://www.reddit.com/r/appengine > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
