filestat

I was looking into whether we could adjust the filestat callback so that
it took as arguments the request, the filename, the mtime of the previous
filestat call, and also the entry object.  That way you could implement a
plugin that skimmed the entry object data and populated the mtime from
data contained therein.  For example, if you had a line in the entry file:

TIMESTAMP::200408161614

the plugin could take that line and extract the date from it and send that
as the mtime.

I see a few complications with this.  First off, we have to change all
uses of the filestat callback so that they retrieve a list of entries
rather than just the list of files and pass those entries into the
filestat callback.  I'm pretty sure I can solve this without further
complications or changing the existing API.

The second issue is more complicated: with the current architecture we may
not open the file at all.  If you're using entry caching, the thing that's
being cached is the parsed file data after entry parsing, not the raw file
itself.

If you're using entry caching, you don't get the raw file, you get the
cooked file after it's gone through tne entry parser.

That just seems messy.  I certainly don't want to build a matrix of what
happens for what configuration.  It's too difficult to explain/document.


I have a couple of solutions for those of you who want to store mtimes in
the blog entry files:

1. We move cache handling from the entry objects to the entry parsers.
The text parser, for example, has no need of caching.  The moinmoin parser
does--because it takes a bunch of time to do its thing.  The entry parser
gets the request object and the filename--that's pretty much all it needs
to figure out whether something is in the cache or not.  This has the
added nicety of the default blosxom behavior being easier to deal with.

2. Those of you building plugins that pull the mtime from the contents of
the blog entry take the filename from teh filestat call, open the file,
read it in, pull out the line you need, and return that.  You could make
this a little easier by caching the mtime in a file.  Or additionally
build an index of files and their mtimes via cron.

3. Some third option I haven't thought of.  (I'm all ears if other people
have other ideas.)


I'm opting for the first one since it cleans up some stuff I dislike (and
wrote in the first place) and it's cleaner for folks implementing
interesting mtime retrieval plugins.  Additionally, it won't affect the
behavior or API except for people who are using caching and entryparsers
that haven't been modified to do the cache thing.

Any thoughts?

/will

-- 
whatever it is, you can find it at http://www.bluesock.org/~willg/
except Will--you can only see him in real life.


-------------------------------------------------------
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