[pmwiki-users] cache

Thu Aug 10 08:28:07 CDT 2006

On Thu, Aug 10, 2006 at 11:02:23AM +0200, bram brambring wrote:
> >  In particular,
> > the page contents cannot be reliably cached for pages
> > containing any of the following markups:
> >
> >   - (:keywords:)
> >   - (:description:)
> >   - (:title:)
> 
> 
> Could you explain why the usage of these markups invalidates caches?
> 
> To me (at least how I use them) these markups are 'stable' for a given page.

Short answer: These markups invalidate the cache because their
output appears in the <head> section of the HTML output instead of
in the body.

Longer answer: It all depends on what one means by "page" when caching.

If we mean that a "page" includes everything in the HTML output,
that is, from the <!DOCTYPE> to the </html>, then you're correct,
keywords, description, and title don't invalidate the cache, because
the cached version would contain the <head> section.  However, it 
also means that the *entire page* is subject to the other 
restrictions I listed before, so that any (:if auth:) directives 
in Site.PageActions or Site.SideBar won't work, login/logout
links can't work, and any author-based preference recipes
(e.g., Cookbook.SkinChange) won't work.

Since there are a lot of sites that have dynamic elements like
these in the skin template (but not necessarily in the body of the
text), PmWiki's server-side caching saves just the HTML of the
wiki markup itself -- that is, the part that appears within
<div id='wikitext'>...</div>.  This is also the part that takes
the most time to generate, so there's a good win there.  Unfortunately,
caching only the markup's HTML output doesn't work for markups
(such as title/keywords/description) that have effects outside of
the <div>.  In order to make those work we'd also have to detect
and cache changes to $HTMLHeaderFmt, $HTMLStylesFmt, and $HTTPHeaders,
and to do this additional caching in a way that works with all of 
the various manipulations various recipes may perform.

So, at the moment PmWiki server-side caching algorithm just
says to not cache any page containing markup with side effects
outside of the <div id='wikitext'> output.  

Aside: In doing all of this I've come to recognize that HTML's
requirement to separate <head> from <body> is rather limiting,
and even somewhat unnecessary.  From a dynamic generation perspective,
things would be a lot nicer if we could just generate <title>,
<link>, and <meta> anywhere in the output.  (For those who would
say that restricting these to the <head> makes somehow easier to
process the resulting HTML, I'd argue that for any real application
it's not substantially simpler.)

Anyway, the bottom line is that if we increase the scope of what
is cached to include the (:title:), (:description:), and (:keywords:)
output, then we inadvertently grab a number of the other dynamic
elements that cannot be easily cached, with the end result that
we're not able to cache much of anything at all.  :-(

As an example of just how hard it is to get caching to work
correctly, look at the amount of work Henrik Bechmann has had to
do just to get browser-side caching ($EnableIMSCaching) to work 
in a highly dynamic environment [1].  And browser-side caching
is far simpler to work with, since a browser-side cache typically
has only one author and one author's preferences to deal with.

Still, if there's a huge demand for it I might see about
some possibilities for caching selected portions of the output, 
or trying to get PmWiki to be smart enough to detect and cache 
changes to $HTMLHeaderFmt, $HTTPHeaders, and $HTMLStylesFmt as
well as the markup's direct output.  Of course, even with such
a system in place, any recipe that makes any non-trivial changes 
to these variables would have to invalidate the cache.

Hope this explanation helps...

Pm