CacheFu sprinting status¶

I pair-programmed on CacheFu today with Maciek Dziergwa. See yesterday's entry for a list of things we could work on.

Fixing unittests

Today's cachfu sprinting started out with fixing the failing unittests. In the first hour, we fixed two templates in CMFSquidTool and fixed one failing unittests: a test that failed if you didn't have an apache running on port 80 on your local machine. That's not very unittest-like, but ok. We now catch the error that occurs and the rest of the tests are running ok.

We added a few if/else statements to CacheSetup that conditionally import code for either plone 3.0 or 2.5, this makes sure the product is usable for both. The change was needed because plone3.0/zope2.10 uses a different page template implementation.

We ran into some remaining test problems:

• The rules defined in CacheSetup's genericsetup.xml seem to disappear from the cache configuration, somehow. strange. Only in plone 3.0, though.
• PolicyHTTPCacheManager also has a testing problem: the result is different in 3.0 and 2.5 due to a change to cmf 2.x. There's a strange message in the doctest: Starting with CMF 2.x any caching policies previously registered with the site are automatically applied to CMF Files and Images in their respective index_html, so we get the cache headers even before associating with our PolicyCache. Anyone know what to make of that?

Genericsetup

Genericsetup support was added by Rocky (and it works like a charm), it only missed the last configuration tab. Nice, bite-sized task. We discovered it was missing the data from the last configuration tab because that data comes from a separate tool (the pagecachemanager) in the plone root, not from AT contenttypes like the rest of the cachefu setup machinery. We didn't get it working yet, basically because there was a missing configure.zcml that prevented the testing mechanism from finding the exportimport adapters. Now I'm getting another error. We'll figure it out.

Handy comments we got during the day

During the day, I got a couple of very handy comments from people that I'm writing down here to preserve them.

• Wiggy suggested what is essential for caching is that someone implements a post-publish and pre-publish events for the zope2 and zope3 publishers. Once you have those you can easily reimplement cachefu cleanly. You want post-traversal-pre-publish so you can look for a cached rendering you can immediately serve and you want post-publish so you can tweak response headers and cache the final rendered output. If it got implemented during the sprint, it could potentially end up in zope 2.11, which would mean plone 3.5+.
• Wiggy pointed me at lovely.viewcache, that caches z3 views so you can strike that from your todo list. Zope3 views, no cachefu evilness.
• Stonor said z3c.responseheaders also looks relevant.
• During the lunch, I talked with Balasz and Alec. The conclusion was that adding the event to zope's publisher wasn't that good an idea. The publisher will change anyway (when twisted will get used). And you probably can't send a response back to the browser from within an event. Balasz has some code in a json server that patches zope's publisher. That might be a good stop-gap measure that replaces three monkeypatches with a single one. And it is something that will work in plone 2.5 and 3.0, too.