On Wed, 2004-03-24 at 03:25, Jamie Heilman wrote:
Chris McDonough wrote:
http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing
Darn, I always forget that cross-posting is bad due to replies to both lists. Sorry. I've limited this reply to the zope-dev list.
Sounds good. WRT your comments on the need for a cache multiplexer so one can handle the case of HTTP cache control headers & opaque server-side caches working together--I'm really wondering if a better solution isn't to just remove the cache header manipulations from where they are now (in a seperate product) and integrate it more into an API any where object [that wants to] can use. HTTP cache control really is a protocol level thing, and the way its bundled as an add-on service right now feels pretty awkward.
I agree... it kinda feels like the services which actually get Zope involved in caching data (RAMCacheManager) should be distinct from those that let other systems know they should cache data (HTTPCacheManager). This is mostly because the need for caching something in an upstream HTTP cache isn't mutually exclusive with potentially wanting to cache it locally too. Well, I guess literally, it probably is (because you probably wouldn't bother caching something in Zope if you could just let Squid do it, at least in the common case), but the adminstrative headache of selectively associating content with "the right" cache manager just seems like too much of a practical burden to make people bear. It would just be way easier to let people be "sloppy" about it by: a) letting people associate content with multiple cache managers. b) creating a cache manager multiplexer (which might expose a bit of policy for dynamic cache selection). c) creating a different cache management architecture that provided caching services based more on policy than on a direct association (ala CMF's CachingPolicyManager). But I really don't have the time to do the work implied by any of the enumerated options. I'll hopefully be able to wait until somebody else gets suffiently indignant about the situation and takes it upon themselves to implement one of the alternatives. ;-)
But anyway, thats a digression from the main thrust of your let them eat producer proposal, which I think is a good idea in general.
Thanks, - C