On 2/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Looks not bad, would this improve the performance?
Using a mod_proxy or a reversed squid in front of this could help a lot. But even just controlling the browser cache with this will improve performances a bit. One more aspect of this is that you theorically can force IE or any proxy to NOT cache your content and thus make sure your method is hit each time the user tries to view it. I have another idea concerning an in memory cache for rendered views that could be controlled with an expose() param specifying the cache_ttl but I need to think about this and to make sure this is doable/useful ... > How about pass only one cache_control params and assign "no-store/no- > cache/max_age" for it? Not sure. This would require string matching which is cpu intensive compared to boolean matching but why not. The problem is I am not an rfc2616 expert but there seem to be much more options and I don't have a clear idea of how to give access to all this easily. The easiest route seems to just give a cache_control parameter and then let the user specify this header by himself (not really friendly but powerful) and the second route is to provided different arguments that help people set an header without having to fully read and understand the rfc2616... I am open to any option. Regards, Florent. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
