Return-Path: 
 <dev-return-18628-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 25628 invoked from network); 12 Aug 2005 20:25:50 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 12 Aug 2005 20:25:49 -0000
Received: (qmail 59968 invoked by uid 500); 12 Aug 2005 20:25:49 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 59941 invoked by uid 500); 12 Aug 2005 20:25:48 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
List-Post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
List-Id: <dev.forrest.apache.org>
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 59928 invoked by uid 99); 12 Aug 2005 20:25:48 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Aug 2005 13:25:48 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [217.199.181.91] (HELO ns3.wkwyw.net) (217.199.181.91)
    by apache.org (qpsmtpd/0.29) with SMTP; Fri, 12 Aug 2005 13:26:09 -0700
Received: (qmail 303 invoked from network); 12 Aug 2005 20:25:51 -0000
Received: from 82-69-78-226.dsl.in-addr.zen.co.uk (HELO ?192.168.0.2?)
 (82.69.78.226)
  by ns3.wkwyw.net with SMTP; 12 Aug 2005 20:25:51 -0000
Message-ID: <42FD05C2.1000701@apache.org>
Date: Fri, 12 Aug 2005 21:25:38 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Reducing Forrest build time
References: <200508090004.55252.diwaker@apache.org>
 <20050809075523.GA17703@igg.indexgeo.com.au>
 <4998884405081210261433dde7@mail.gmail.com>
 <379934925.20050812214018@soethe.net>
In-Reply-To: <379934925.20050812214018@soethe.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Ferdinand Soethe wrote:
> 
> 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.

[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?

>>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?

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* 
page).

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 
structure.

How do we know what to regenerate? Use the checksums you describe above 
to create a list of pages to regenerate.

Ross