[Zope] Brainstorm: Zope behind proxying cache?

[Paul Everitt]

Jonathan wrote:
> Been brainstorming a little while about modifying HTTP requests
> combined with a high speed cache in front of a dynamic source of
> data, such as Zope.
> 
> Idea: Put a proxying cache with content negotiation, rewriting of
> requests etc. in front of Zope. First time a page is requested
> (client requests it from the proxy which knows where to get it
> because it's configuration files tell it how to handle a request) it
> is cached. The next request is served directly from the cache. As
> soon as a page changes it is fetched from Zope and cached again.

The problem is: what is a page?

For instance, if you got to http://www.zope.org/, you'll get a different
page than me.  Why?  Because my page is personalized.  However, the HTTP
header Etags could help by giving each version of a page a unique id.

> It would also allow you to use any mix of static and dynamic content,
> because pages that stay the same are served directly from the cache
> and Zope is never hit to serve that page. Allows to use Zope as a
> content management tool too.

The win these days is in smarter caching which is more finely-grained
than at the page level.

> So what's your view? I know that a request can be modified behind the
> scenes based on the data the client supplies - request, filetype,
> language, browser type, IP address etc. It's also possible to cache
> the files requested, but I am not sure how the cache would
> communicate with Zope and vice versa.
> 
> The HTTP protocol offers some hooks to cache a file for a limited
> time only if I am not mistaken, but the ideal solution in my view
> would be a button in Zope called 'Publish' which would send a message
> to the cache resulting in the removal of that particular page...

I _think_ that Squid has a protocol like this to allow caches to send
messages to each other.

--Paul