[Pmwiki-users] Re: 404 caching

[J. Meijer]

Hi Evan,

Since a post is an infrequent operation, some time could be invested to find
the pages that need to be flushed from the cache. My response indeed did not
address this aspect. I also missed the aspect of new and deleted pages. So
just to summarize:

Instead of calculating dependencies these strategies can be applied:
- flushing of a whole group for pages (like GroupHeader, menus) which
exist for the sole purpose of being included;
- flushing of the entire site only for very urgent updates that affect an
unknown number of groups;
- do not directly include volatile data in a page, instead use some sort of
frame and let the browser handle it separately;
- add an [update] link that forces the latest version to be generated. Only
essential when editing data on another page which is being included on the
current page;
- users requiring this instant feedback can be detected using session data
:-)
- this also largely resolves the problem of new and deleted pages requiring
an update on their link-format.

Indeed very few cases will be missed and the hourly refresh will take care
of these. Perhaps even better then the detection algorithm, because
dependencies might be introduced indirectly, by an included page including
another?

That said, having backlinks available for a page is something a
next-generation wiki needs to support directly.  You could relax your
efforts until pm's word on pmw2 is out.

-jm




ps Did you reckon with dependencies imported from within the .tmpl?


  ----- Original Message -----
  From: Evan Prodromou
  To: J. Meijer
  Sent: Thursday, July 08, 2004 3:10 PM
  Subject: Re: 404 caching


  J. Meijer wrote:

  >You mention in your TODO:
  >- need better invalidation, now 404-chache invalidates all of the cache
  >after an edit.
  >- need cache management to limit cache size. So cache only a number of
  >pages.
  >
  >It struck me that both needs can be met through a simple rule: invalidate
  >the page after it has been there for an hour. Or after it has been
edited.
  >When there is high traffic on a page, it will come from cache, otherwise
  >pmwiki will regenerate it. So when the site suddenly becomes the hit it
is
  >supposed to be, the wiki-server won't go down.
  >
  >
  So, the main thing is that when you change a page, there may be other
  pages that depend on the state of that page for their content. Some
  examples:

      * If the page is new, other pages that link to it will still have
        links in the "missing page" style. They need to be regenerated to
        have the "existing page" style.
      * If the page is being deleted, the opposite happens. Linking pages
        still need to be invalidated.
      * If anything includes the page, the cached version will contain the
        old contents. So those need to be invalidated, too.
      * If GroupHeader, GroupFooter, or $Group.SideBar change, the
        appearance of all the pages in the group change. So all the group
        pages need to be updated.

  It's tricky to figure out all this stuff, but I think it's possible. I
  wrote up a WhatLinksHere module to try to figure out these dependencies:

      http://www.pmwiki.org/wiki/Cookbook/WhatLinksHere

  ...and I'm going to try to make the 404 cache work with it in the near
  future. The general strategy being that when a page is edited and saved,
we:

     1. Invalidate the cache page for the currently edited page.
     2. Invalidate the cache pages for any pages that depend on the
        current page (per WhatDependsOn()).
     3. If this is a new or deleted page, invalidate the cache pages for
        any linking pages.

  The advantage here is that we only invalidate cache pages for pages
  actually affected by the change.

  >Indeed (a patched) pmwiki could assist the WhatDependsOn and
WhatGoesHere.
  >Should you really require these functions, I'm not convinced yet.
  >