Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Message-ID: <000601c43b60$2b7bf660$be8cea43@sybase.com>
From: "Adam R. B. Jack" <ajack@trysybase.com>
To: <forrest-dev@xml.apache.org>
References: <0e8101c439ca$c68134f0$4bb5ea43@sybase.com>
 <1084590524.1306.2104.camel@ighp>
Subject: Re: Forrest Gump
Date: Sat, 15 May 2004 09:31:47 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Do you need to move to using the webapp? Perhaps that would
> be great. We could also ensure that other incarnations do what
> you need (i.e. the command-line 'forrest' and 'forrestbot).

Yup, webapp seems the right thing. As you see from Nick's posting, he's
installed it [an older one], and we are now using it. :-)

        http://brutus.apache.org:8080/gump/index.html

The command-line 'forrest' served us well, but since we created thousands of
pages (and a bunch of large SVGs) it was consuming a lot of cycles, and most
likely generating/regenerating pages that nobody read (in the page
lifetime).

Well, I'd like forrestbot for keeping the Gump project site
[http://gump.apache.org] up to date, but we can be patient. :-)

> > (1) to only skin what is requested/viewed & to save time/cycles
>
> Perhaps webapp would be more efficient than a static build.
> Who knows how to measure such things.

In our case it seems easy, build the N pages folks read [only when they read
them] verse a few thousand every hour or so.

> How often does each set of documentation get rebuilt?
> I know, you are going to say: ideally constantly being updated.

Basically every hour or so we rebuild the whole site (and we do it on a few
servers, although not so frequently on others).

> The "copyless" approach and the webapp do sound like the way.

I still don't understand what this is exactly verses what we have, but we'd
like to update to pretty recent (and seems we ought wait for that merge). I
think we need some SVG -> PNG fixes in recentish release of Forrest ('cos
they seem to fail on older).

> > (2) to be less sensitive to validation issues.
>
> Examples please. We are refining this sort of stuff, especially
> skinconf.xml

The issue is simple for us, and probably not like many of your more complex
validation issues. If we are doing batch for 5 thousand, and we have one bad
page (one user cat'd a binary file out to 'screen', which became our page),
we loose the whole site. None of the 5 thousand are produced. There used to
be a switch to override this, I beleive (per Google), but I couldn't get
this to work with recent Forrest & I think it has been lost as a feature.

Basically w/ webapp it seem to me that one broken xdoc means one broken
page, never worse.

> > We have this approach working on another server, on an older Forrest,
but
> > would like to use the latest/greatest Forrest & keep current. We know
you've
> > been working on the 'copyless',
>
> Yes but not yet ready for production.
>
> > and I wonder if you'd be game to attempt to
> > install/manage/maintain this, once merged (or whenever), onto Brutus.
>
> It would certainly be an excellent test environment.
>
> The "you" might not contain enough people at this stage.
> Let's keep talking and see what happens.

Sure. We'd like the Forrest Gump site/integration to be a prime example, yet
right now it is suffering from our lack of knowledge. I know you guys are
busy w/ your own priorities, but I hope you'd find some value to them in
doing this with us.

regards,

Adam