Re: filestat

I'm looking at 2. with an index file. I was concerned that pyBlosxom would  
walk through the whole datadir everytime it was invoked. The price is even  
heavier if in addition it has to read inside each entry. The index file is  
to kill two birds with one stone. Perhaps we can add another command line  
option to pyblosxom.cgi to do the indexing so that they can make use of  
the same framework and configurations instead of writing a separate script.

Another question perhaps you can help is how do we lock a file from CGI,  
in particularly in Linux? I wonder what would happen if the index update  
and pyBlosxom were invoked at the same time.

Wai Yip



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




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