[Radiant] Ideas for reimplementation of radiant caching

[Sean Cribbs]

>
>
> - It's annoying to have to clear page cache after every edit in order to
> view your change.


The cache is automatically cleared for the page you edited, but only that
page.  If you edit a layout or snippet, the whole cache is cleared.

Also, I see no reason why we can't attach a Preview button directly to
> each page edit screen.


I think this would be a nice feature too.  PDI?

Well then can we make Apache serve everything?  Why not have the options
> to make Radiant generate a full directory of HTML files.  A possible way
> to support having select pieces of the site be dynamic is to use Apache
> server side includes to make calls back to Radiant for specific pieces.


This would be an ideal case, but I think the path Radiant takes is a good
compromise.  The advantage of Radiant's caching system over static files is
that you can include headers.

I know you're probably using Apache in a figurative sense, but not everyone
uses Apache. kckcc.edu runs quite speedily and effortlessly (excepting the
site map) on Litespeed.  We use the built-in LSAPI Rails bridge, which is
purported to have a 30% boost over FastCGI.  There are other ways to eek out
performance too, not all of which have to do with the caching.

Are there any other reasons for changing Radiant's caching?


I don't see any.  It's "good enough" for most cases, I believe.

The unmentioned alternative, of course, is memcached.  It would take minimal
changes to the code, probably a single line in environment.rb, since
ResponseCache piggy-backs on the Rails caching mechanism.  However, not
everyone could run memcached.

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.radiantcms.org/pipermail/radiant/attachments/20070123/6f212337/attachment.html