Tim and David wrote:
>> > What are the best ways of >> > approaching it? (avoiding building unchanged document is the obvious first >> > step I guess) >> >> Well yes, but that issue is complex. Evidently >> Ferdinand talked with Cocoon people at ApacheCon >> and might now have some answers. > Ferdinand, I'd also like to know what you discovered with the Cocoon > folks on this not building unchanged everything. Well I basically discovered that <checksums-uri> in cli.xconf is functional and works though I haven't figured out why it didn't work when I tested earlier this year and I haven't had the time to thoroughly test its function for all kinds of situation. However I can already state that this is not going to reduce our build time because of the way checksums works: - Create or update a checksum for each document each time it is build - Next time compare that checksum to the checksum for the newly build document before it gets written and if they are the same, don't write it again. So checksums are great if you want to use simple sync mechanisms to upload your static site (because unchanged files are not written again and don't have their date stamp changed) but it is no good as far as build times are concerned because all the building steps have to happen time and time again. So what we are really looking for is a way to make Cocoon save their caching of each pipeline from (client-)session to session. That way Cocoon will use all it's fancy mechanisms to determine the exact point in the pipeline where it needs to start rebuilding so that we don't have to worry about questions like 'has a menu changed' etc. >> One thing to bear in mind is that each time we >> enhance the pelt skin, then *all* pages need to >> be re-generated even though their content hasn't changed. True but not true. As far as I understand pipelines Cocoon (in a dynamic environment) will recognize which inputs have changed and will only rebuild from there. Which will save a lot of time on larger docs. >> Also adding a new page means changes to the navigation menu >> which means regenerating lots of pages that haven't changed. Ideally only rebuilding the menus and merging them with the unchanged parts of the page, not? > For these two, skin changes and navi changes, this may be really dumb > (haven't fully thought it through) but how bad would it be to have a > different target for builds intended for a web server so that we could > utilize server side includes? I don't understand how serverside include would solve any problem other than inserting date-stamps? -- Ferdinand Soethe
