i was pondering how to speed up some complex pages for authenticated users and I had an idea. the gist is to almost exactly emulate block caching but applied to the return value of the hook_menu's 'page callback' rather than hook_block('view').
in d6, a contrib module could use hook_menu_alter() to point the complex paths to its own page callback and then move the existing page callback so it is the first item in 'page arguments' array. when our new page callback receives control from the menu, it checks cache and returns the cached value if possible, else it delegates to the original callback, caches its return value, and returns the return value. in additional we need an array of paths and their cache strategy (PER USER, PER_ROLE, etc.). i think we can just store that value as the second item the altered 'page arguments' array.
any further ideas? you think this makes sense as a core patch for d7? it would be cleaner there - no funny business with page callback and page arguments.
Comments
Interesting
That would make for a great rewrite of boost, as well as a nice new target for memcache. Are you working on proof of concept code?
Who knowns when a page is different per user, role, etc?
That's a problem because any component of the theme system could render data that's different per user, role, etc. So every single piece in the system that's able to generate output would have a need to influence the cache page ID. "Dear cache system, I'm generating this piece of content that's per user/role. Please, alter the cache id for this page accordingly. Thanks. :)"
Maybe the one who renders output could generate placeholders (tokens) for the parts that may vary (per user, role, etc.) when cache is enabled, and those tokens would have to be replaced when that page needs to be retrieved from cache and served for real.
As an idea, to do this, maybe those tokens (and their callbacks) could be exposed from hook_theme(). When the theme system executes a theme funcion who exposed tokens, then it could tell the cache system to cache that information as well, so the cached page would hold the rendered page and information that could be used to replace any token that was in there by calling token callbacks.
pressflow preempt (panels)
This sounds quite similar to http://drupal.org/project/pressflow_preempt_panels which depends on http://drupal.org/project/pressflow_preempt
I think this makes sense - though as Markus points out the knowledge about which pages to cache is hard to determine.
knaddison blog | Morris Animal Foundation
@Robert - no code yet. i
@Robert - no code yet. i might undertake this if i find some time or need.
@markus_petrux - yes, that would be needed if the system were to self determine the cache strategy of each page. i was thinking that an admin would do that by defining an array in settings.php. the array would map path to strategy. so it is up to the admin to know whats appropriate for the pages on his site. any better scheme would be more complex. your suggestion about theme tokens is pretty interesting though.
greggles - yes, very similar. i remembered about pressflow after I wrote this up. i still didn't know about its panels feature. funny how the system design is nearly identical.
Potentially related idea / issue
I posted http://drupal.org/node/300935 a few months ago. Basically, the system would need to know which pieces of content are dynamic / user-specific; we could cache everything that is not user-specific and insert the bits that are dynamic on-the-fly at generation time. Those could even be cached separately on a per 'block' basis?
Maybe taking advantage of theme registry?
So maybe hook_theme() could be enhanced with a new item named 'postprocess function' or something similar.
When cache is not enabled, theme functions and its registered postprocess function would be called one after the other. The theme function would generate placeholders where content would go, and the postprocess funcion would replace those placeholders with the real content.
When cache is enabled, the theme function would be called at page generation time, and postprocess functions would be called when the page really needs to be served.
Cached pages would have to be saved with enough information about theme functions with registered postprocess functions so the cache system would know what to call and how before sending pages.
PS: I also posted about something similar here, which is something I'm using on live site, but that's somehow hack-ish and very site specific.