Re: filestat

On Wed, 18 Aug 2004, David Ascher wrote:
>
> Is there any scenario where multiple entry parsers can be run in
> parallel, in which case the caches need to cooperate?

Good question!  We have a couple of mechanisms that plugin developers can
apply to transform text before it gets rendered:

  1. entry parser -- Each entry parser is bound to a file extension.
     The default entry parser is bound to ".txt".  Any file that has
     that extension passes through the default entry parser.  Only
     one entry parser gets used for a given entry.  This is perfect
     for people who hate writing html and want to write wiki or reST.

  2. preformatters -- I get a little fuzzy why this exists.  But this
     and the entry parser give everyone a two-pass formatting of the
     entry.  The preformatters are implemented as a callback
     (cb_preformat) so many preformatters can transform a given entry.

  3. postformatters -- This is good for extracting metadata from
     the entry.  This step is handled by the postformat callback
     (cb_postformat) and is good for macros or acronym expansions.
     Many postformatters can transform a given entry.

After entry parsers, preformatters and postformatters are called, the
data from the entry is cached by one of the caching mechanisms assuming
the user has that enabled.

After that phase, the plugin can further transform things in the story
callback or prepare callback.  The results of transformation changes in
those two places aren't cached.  So that's where you'd want to do things
like highlight words that the user searched for in google, state how many
comments are associated with the entry, or other non-static things like
that.

/will


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285