On Thu, 26 May 2005, Gerhard Killesreiter wrote:
My conclusion is that our cache needs to be more finely grained (right, that's not new).
For example: Comment.module calls cache_clear_all() after a comment has been added. Granted, thanks to our block system it can happen that some comment (or comment count or "last updated" ...) is displayed on just any page. But I'd prefer modules that provide such blocks to build their own block cache and invalidate cached pages according to the blocks' path settings.
Note that the block caching is not a prereqisite, we could do without. Most blocks would need per user caches.
That should not be too difficult. The same should be done for blocks that display content based on newly created nodes. Those modules should take the cache setting (none, loose, strict) into account.
For comment.module that would mean that it only sets variables (comment_last_timestamp, comment_last_uid, comment_last_nid, comment_last_cid) to new values instead of invalidating the cache. forum.module would then check the variable against its own variable (forum_last_time_page_rebuilt) and invalidate pages as appropriate.
That's of course nonsense, the modules would need to implement the comment api.
Same for tracker and other modules that deal with comments in one way or the other.
Most modules that display nodes or listings of nodes deal with comments too by showing "n new comments". Nodes can be shown in multiple contexts: /node/nid /foobar/nid (not often) /node /tracker /forum /taxonomy/.... I propose that we let comment module clear only /node/nid and let modules that show nodes in other contexts delete the appropriate pages. Deleting taxonomy pages might be a bit difficult, haven't checked yet. if it is too diffcult to find all pages that should be deleted, we could make it adopt a different policy, ie only delete all taxo pages after the nthe commment has been committed. Cheers, Gerhard