Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <430BC504.2050903@apache.org>
Date: Wed, 24 Aug 2005 02:53:24 +0200
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Add support for Googles sitemap protocol?
References: <80d298bc05071311181b5c35b8@mail.gmail.com>
	 <42D584CB.30300@apache.org>
 <42D5960F.3050507@apache.org>	 <80d298bc050713161262ca8f21@mail.gmail.com>
	 <42D5A724.4000808@apache.org>	 <80d298bc0507132243420ef815@mail.gmail.com>
	 <42D610BF.6020006@apache.org> <80d298bc05072212313281e75c@mail.gmail.com>
In-Reply-To: <80d298bc05072212313281e75c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rasik Pandey wrote:
> Hello,
> 
> Ross wrote:
>  >>http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/generation/LinkStatusGenerator.java 
> <http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/generation/LinkStatusGenerator.java>
>  > > would do the trick, although it would have to be modified to make a 
> call
>  > > to get the "last-modified" header, so hopefully we could get that added
>  > > to a future release of cocoon. With a quick examination of the 
> code, it
>  > > looks like it will crawl a URL and generate an xml report, allowing
>  > > includes and excludes expressions.
>  >
>  > We can create a new generator that extands the LinkStatusGenerator and
>  > house it here. If Cocoon want it we will remove it from here at a later
>  > date.
> 
> I have a few issues with the approach which I proposed, hopefully you 
> can help me make some sense about my reservations. First, since views 
> are orthogonal to each sitemap the cocoon-view=links required by the 
> LinkStatusGenerator and therefore must be declared in the parent sitemap 
> which does the core matching.

Agghhhh!!! There's that term "views" again.

We have a real problem here in Forrest at the moment. Views are being 
used to refer to two different things (views in Eclipse and views, the 
replacement for skins). Now we seem to have a third use, I assume this 
is sitemap views (funnily enough I said this may become a conflict in 
another mail earlier today, never thought it would already have happened 
in my inbox).

I'm going to delay responding to this because one of the things that 
happened at the Hackathon is that Ferdinand looked at an alternative 
method of identifying which pages were regenerated in a run. Perhaps we 
should wait to see if he thinks it can be applied here.

> Secondly, in building such a plugin for 
> forrest, the plugin-sitemap would have to override/redeclare a number of 
> pipeline match(s)  in order to have access/provide to the necessary 
> request header,"last-modified", as there doesn't seem to be a generic 
> means for providing this information and passing it up to parent 
> pipeline match(s) so they are conditionally added to the request 
> headers. Overriding many pipelineThis doesn't seem very maintainable. 
> Would anyone have any ideas on how to achieve this or an alternative 
> approach?

Internal plugins are for this kind of thing. However, as they stand they 
don't make the code much more maintainable.

A possible solution is to use Cocoons new block sitemap loading 
features. This was demonstrated to me at the Hackathon (thanks Daniel), 
it provides a way for plugins to extend existing sitemaps (and other 
plugins). I need to do some experimentation with this so you should 
proceed with an internal plugin for now, we'll address the 
maintainability when experiments are complete.

Ross