On 27 Jun 2003 at 12:09, Unico Hommes wrote:
> > > That's what I want too! But it does not require that the
> > actual runner
> > > be implemented as a sitemap component or executed as part of a
> > > pipeline. PublishServiceStatusGenerator can still access the
> > > PublishService as a component from the ServiceManager.
> >
> > I agree. Have a sitemap component that calls a publishService
> > that runs in the background.
>
> OK, I do see your point. It still feels like a feedback loop.
Maybe we need to make sure that the Bean's Cocoon can't run the publishing
service! :-)
> > > > > Great! We could eventually also supply a way to delete remote
> > > > > resources when they no longer exist locally.
> > > >
> > > > Should be possible. If you have some understanding of the Cocoon
> > > > Cache, you can probably help me get it to work.
> > >
> > > I was thinking more in the direction of keeping all the
> > generated link
> > > views during run A and comparing it during run B to the
> > current ones.
> > > That way non-caching pipelines work too.
> >
> > My 'only generate changed content' code uses the
> > 'last-modified-since' functionality recently added to the
> > HTTPEnvironment. You need to store locally the timestamps of
> > files when you generate them, and the links that are held
> > within the page (so that you can follow them when the page
> > doesn't need generating).
>
> If the remote files are read-only, then you could also check the
> last-modified of the remote file. But probably your solution is faster
> because it doesn't require an additional network call.
That's the point - avoid network traffic.
> > The code is all there, but for some
> > reason Cocoon isn't calling my setResponseNotModified(),
> > which it should, and I haven't had time to check out why. As
> > to deleting, you can just check if a file is in your store
> > that wasn't spidered this time, and thus delete it.
I'll get looking into this again soon (next) - but would appreciate guidance when it
comes to working with Cocoon's caching.
> > > > Oh, I'm in the process of reworking Main.java and the
> > bean to add a
> > > > BeanListener interface. That means that the bean does not do any
> > > > outputting to System.out. It just calls methods on the Listener
> > > > interface - the bean caller needs to register a listener with
> > > > the bean. I've moved the broken link reporting into Main, so
> > > > that the bean simply reports a broken link, leaving it to the
> > > > user
> > to decide
> > > > exactly what should happen when a broken link is found.
> > Here's the
> > > > interface as it is at the moment:
> > > >
> > > > public interface BeanListener {
> > > > public void pageGenerated(String uri, int linksInPage, int
> > > > pagesRemaining);
> > > > public void messageGenerated(String msg);
> > > > public void warningGenerated(String uri, String warning);
> > > > public void brokenLinkFound(String uri, String message); }
> > >
> > > Ah good, this also works towards making CocoonBean thread
> > safe. I like
> > > it.
> >
> > I'm glad. It doesn't yet work, but I'll commit it when it does.
It is now committed. Do take a look (and let me know of any problems).
Regards, Upayavira
