One idea is the construct the key for the data you’re caching in a way that it is the same, regardless on where you get the data from (which is often irrelevant as you point out). For example, an addon’s uuid+”title” to get its title?

It’s a nice idea, but with the way CakePHP works (straight queries with joins, etc. to the database) it wouldn’t work. We’d have to rewrite a lot of the core Cake code.

It’s actually a pretty similar idea to what the patch does – it stores arrays of the query hashes themselves so we can invalidate them later (using a reproducible key). I wrote a few paragraphs about what it did but it seemed a little long winded for the original post. I put the description in bug 425315 comment #8 instead.

For the different-links-for-different-people case, I would suggest creating a single page with everything in it, and then serving hide-admin/hide-developer/hide-localizer CSS rules in a tiny non-cached CSS file for the current user if they’re logged in. You can do the same with JS to stick the user’s name in the right place if needed. <noscript> blocks in the content can provide a boring-but-workable alternative for the few who turn off JS for the site.

I think we’re starting to do this in a few places already as we rewrite stuff, but it’s definitely a direction I see us going.

If you just invalidated the main add-on page on any developer edit, and the rec-list/front page, but left search to expire over 15 mins or whatever, do you think that people would still complain?

Heh, probably , but it would be much more reasonable that what we have. If we can expire the main add-on page and the API (both relatively easy compared to search) I think we’d be in a pretty good place.

Also, instant invalidation is not necessary if you do the above, and make sure to overwrite the previous entry as soon as it is updated with the new value.

Explicit invalidation is definitely the way to go, if you can do it, but as you say that requires a fair amount of book-keeping to know what gets invalidated when. Does search invalidation need to be on the same schedule? If you just invalidated the main add-on page on any developer edit, and the rec-list/front page, but left search to expire over 15 mins or whatever, do you think that people would still complain? It would not be Truly Pure, but the main use cases (I made a change to my add-on, and want to make sure it looks OK, etc.) would seem to be well-served.