[pmwiki-users] Speedy search?
Joachim Durchholz
jo at durchholz.org
Wed Feb 22 15:19:47 CST 2006
Patrick R. Michaud schrieb:
> Assuming we cache the contents of MarkupToHTML, here's an updated
> list of things that cannot be reliably cached:
>
> - read access restrictions on the page, or read access restrictions
> of any included components of the page
> - markup that is based on visitor permissions or identity
> (:if auth ...:)
> (:if authid ...:)
> - markup that acts differently depending on form or url parameters
> (:pagelist:)
> - any markups that are time sensitive
> (:if date ...:)
> - markups that change skin settings
> (:noleft:), (:noright:), (:noheader:), (:nofooter:)
> - markups that add <meta> and <head> output
> (:keywords:), (:description:)
> - markups that depend on external files
> (:if attachments:)
How about caching sections of pages?
E.g. the stuff within an (:if:) block, and the stuff outside of such
blocks. PmWiki would still have to evaluate the (:if:) condition and
select which subsections to include in the generate the page, but it
wouldn't have to re-render the rest.
Other option: Have a "cache the page" markup rule. It must be after most
markup has been processed but before those uncacheable rules are
applied, and simply saves the page in the current processing state
(needs to save the Keep array, too). Whether this one is feasible
hinges on the question whether uncacheable directives are done late in
the sequence (or can be made so) - I'm somewhat sceptical whether this
restriction on markup markup design is the Right Thing.
Considering that markup authors shouldn't be required to be caching
experts, the default for a markup should be "uncacheable". Given that
most markups are part of the core and can be marked cachable, this
should still give most of the effect with a minimum of instability.
Just some unorganized late-night thoughts.
Regards,
Jo
More information about the pmwiki-users
mailing list