Rasik Pandey wrote:
> This is a good point. How about also also providing a generator that
> would get the last modified header of remote resources. The results of
> the two could be aggregated together.
I think
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.
> However, this still is not totally robust, becayse some remote resources
> will always indicate that they have changed even when the content has
> not (for example Daisy tracks changes to meta-data that Forrest does not
> currently use).
What strategy do you propose to handle this case if any?
This is a special case. I would not worry about it just yet. The Daisy
plugin is still in the whiteboard anyway. In fact the one that is in SVN
right now would work with the above approach, it is the one on my hard
drive that would have a problem.
>> I may need some assistance to know how to build in hooks from
>> skinconf.xml to the sitemap format generation.
> I'm not sure what you mean by that. But there are plenty of people here
> to answer your questions as they arise.
I am sure there will be a need to allow users to specify a configuration
for this like the includes/excludes on the LinkStatusGenerator crawls
and maybe the <changefreq> value for the google sitemap format. Can you
give me a quick overview of how params make it from the skinconf.xml to
the sitemap(s) or xsl(s)?
This should not be configured from skinconf.xml. There a few reasons for
this, firstly it has nothing to do with the skin, which is about the
look and feel of the site. Secondly because skins (and therefore
skinconf.xml) are being deprecated in 0.8 in favour of views. Finally
this should be an output plugin and therefore needs to be configured
from the plugin.
The variables in the sitemap, such as {project:stylesheets} are defined
in forrest.xconf and are given values from forrest.properties during Ant
script (the init target if I remember correctly). However, since this is
a plugin we do not want to be adding new config values to
forrest.properties. So again, the config needs to be in the plugin.
How do you do that?
We don't know yet. We have discussed it quite a few times but have not
yet come up with a final solution. Although Thorstens recent work on
View configuratoin has made some of the options we talked about possible.
Since we don't yet know a solution for this perhaps we can work the
other way around. When you get to the point of needing to add these
configurations tell us exactly what you need to do and we will use it as
a use case for defining the per plugin configs.
Ross
