[Zope-dev] proposal: serving static content faster

[Chris McDonough]

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