cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira" ...@upaya.co.uk>
Subject RE: Cocoon resource publishing
Date Fri, 27 Jun 2003 13:50:05 GMT
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



Mime
View raw message