> > 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.
Sometimes this kind of information gets lost so here is a reminder: The Corex branch (an experimental transition from Trunk to Mental) has had a working implementation of a new caching mechanism that writes files to public/ once they are requested (GET). Since public/ has precedence over the application controller you can get extremely good performance results. Unfortunately, this type of static caching turned to out to be inflexible because headers cannot be cached. Otherwise it would have been a powerful alternative to the current caching mechanism. Too bad headers can't be reliably modified with <META> tags. On 1/23/07, Sean Cribbs <[EMAIL PROTECTED]> wrote: > > > > > - 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 > _______________________________________________ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: > http://lists.radiantcms.org/mailman/listinfo/radiant > > -- Alexander Horn http://www2.truman.edu/~ah428 . _______________________________________________ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
