forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Reducing Forrest build time
Date Tue, 16 Aug 2005 08:13:39 GMT
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>>[OT - but related] This is perfect for the Google Sitemap plugin that
>>has recently been contributed to the whiteboard. Are there any docs on this?
> No. Haven't gotten around to test this a bit more so there is really
> not much to document. Feel free to ask if you have any questions.

I meant docs in Cocoon - but if you write Forrest focused docs one day 
that's even better :-) (david linked to the cocoon docs for me already - 

>>>I don't understand how serverside include would solve any problem
>>>other than inserting date-stamps?
>>Without SSI all navigation, tabs, and other page decoration is a part of
>>the served page. So a change to the skin/view results in every page 
>>having to be regeneerated (yes you could do cleaver stuf with caching,
>>but you will still have to do the final stage of processing for *every*
>>Using SSI the page decorations are not a part of the served page as 
>>generated by Forrest, instead they are separate files that are pointed
>>to by the generated page. So, for example, a change in the navigation
>>structure only requries a single file to be regenerated - the navigation
>>How do we know what to regenerate? Use the checksums you describe above
>>to create a list of pages to regenerate.
> Hmmm. Thanks for explaining that.
> Though now that I understand it I think even more that this is
> re-inventing the wheel.
> Let me explain:
> By using ssi to create decorations like menus and tabs you are
> basically doing what a dynamic Forrest would do in assembling a page
> on the fly (true, the actual mechanism of resolving a ssi is
> different from a transformation). The only real difference being that
> Forrest/Coocoon alread has mechanisms to determine which parts of the
> page are unchanged while for ssi we'd have to create them (Although
> some smart systems might actually cache the ssi-content and as a
> result be as good as Cocoon.
> By using Cocoon's pipeline and an active server we can already tap into
> a highly refineded system and achieve the same of better results.
> By making the Cocoon cache persistent between session we could even
> have this for a static page.
> No?

I see your point and agree with the theory. So will it work in practice?


View raw message