Jason Blevins | 25 Mar 23:50
Picon
Favicon

Re: hybrid mode based on GET vs. POST

Hi Kevin,

Kevin Scaldeferri wrote:
> My thought at this point is that the primary reason to have entry  
> pages be dynamic is to a) be able to process comment submissions, and  
> b) display new comments in a timely fashion.

I agree completely.  I hate making my server do the same work twice.
I had a hybrid setup like this for a while.  Everything was static and
regenerated only when something changed (primarily when a new comment
was added).

> It seems like (a) could  
> be easily achieved by changing the rewrite condition to only do  
> dynamic for POSTs:
> 
>      RewriteCond %{REQUEST_METHOD} =POST
>      RewriteRule ^(.*)$ blosxom.cgi/$1 [L,QSA]

That's exactly what I did except I also passed requests with query
strings to Blosxom in order to accommodate other plugins:

    RewriteCond %{QUERY_STRING} "!^$" [OR]
    RewriteCond %{REQUEST_METHOD} "POST" [NC]
    RewriteRule (.*) cgi-bin/blosxom.cgi/$1 [L]

You could also first check to see if the static file exists and have
Blosxom serve everything that's not a file.  I'm not completely sure if
this is correct, but something like this should do it:

    RewriteCond /path/to/static/%{REQUEST_URI} -f
    RewriteRule ^(.*)$ /path/to/static/$1 [L]

    RewriteRule ^(.*)$ blosxom.cgi/$1 [L,QSA]

> Then for (b) I would need to modify the feedback plugin to trigger a  
> rebuild of the static page.  This might be trickier, since I don't  
> think there's any way to get the static rendering system to regenerate  
> only one page.

I did this by deleting the files I wanted to regenerate (the story page,
main index, and any feeds with comments) and calling Blosxom in static
mode to recreate them.  To do this I wrote a small plugin which I called
static_helper [1] and modified the feedback plugin to call it when a
comment was submitted:

    if ($blosxom::plugins{'static_helper'}) {
        my $static_file = "$fb_path/$fb_fn";
        $static_file =~ s/\.$fb_extension$//;
        static_helper::regenerate($static_file, $blosxom::default_flavour);
        static_helper::regenerate($static_file, 'atom');
        static_helper::regenerate('/index', $blosxom::default_flavour);
    }

Blosxom is running in dynamic mode to serve a specific page request when
these calls are made.  Calling blosxom::generate() again at this point
will not do what we want.  The static_helper::regenerate subroutine
basically stores a list of files and then in the end() hook, it deletes
them, forks, and calls Blosxom in static mode.  Then the original
request (the comment POST) can return while the forked process
regenerates the pages.  Otherwise the user would have an unnecessarily
long wait.

Before I worked out the kinks in the hybrid approach I wrote a page
caching plugin [2].  The downside of caching is that every hit still
requires a call to Blosxom.  However, very little processing needs to be
done since skip() is used if the requested page cache exists and is
still fresh.  It would definitely still help for high traffic pages
though.

Keep in mind that both of these plugins are completely experimental
(although I used them in production without losing any sleep).  I'm not
planning to work on them since I don't use them any longer but other
people should feel free to hack on them.

Best of luck in hybrid mode,

Jason

 [1]: http://code.jblevins.org/blosxom/testing/static_helper
 [2]: http://code.jblevins.org/blosxom/testing/page_caching

--

-- 
Jason Blevins <jrblevin@...>
http://jblevins.org/

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Gmane