cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: Cocoon resource publishing
Date Fri, 27 Jun 2003 10:09:02 GMT
 

> 
> -----Original Message-----
> From: Upayavira [mailto:uv@upaya.co.uk] 
> Sent: vrijdag 27 juni 2003 11:51
> To: cocoon-dev@xml.apache.org
> 
> On 27 Jun 2003 at 11:40, Unico Hommes wrote:
> 
> > > If you don't want it to be a sitemap component, how else 
> would you 
> > > propose to do it?
> > > Somehow it needs to be under the control of the sitemap so as to 
> > > exist as a part of the URI space.
> > 
> > Part of the URI space could be dedicated to the publishing 
> service by 
> > declaring a servlet mapping for it in web.xml or if you want all of 
> > the URI space in the cocoon webapp dedicated to 
> CocoonServlet put it 
> > in its own web context. Another possibility is that we could extend 
> > CocoonServlet's capabilities and responsibilities.
> 
> I prefer your later suggestion...
> 
> > > > I think that the role of the sitemap and its components 
> should be 
> > > > more or less constrained to creating documents.
> > > 
> > > Hmm. Not so sure - you've got Lucene that has a page to 
> generate an 
> > > index. Are there not other examples too?
> > 
> > Yes a lot. But I don't like them. Lucene may be a positive 
> exception 
> > though.
> > 
> > > The
> > > thing is, that if you create a sitemap component, you can build 
> > > around the publishing service a web site for deployment. 
> Imagine a 
> > > site that you log onto (e.g. using the authentication framework). 
> > > Then, Cocoon reads a database to find out what sites you 
> are allowed 
> > > to publish, and offers you a drop down list of those sites. Maybe 
> > > pages need deploying in a specific sequence, so this 
> sequence can be 
> > > managed by the flow. And when you want a page, pages or a 
> site to be 
> > > generated, you click 'go', and off it goes, probably in the 
> > > background, allowing you to get on with other stuff. Then 
> you might 
> > > have a 'status' page, based around a 
> 'PublishServiceStatusGenerator' 
> > > that can tell you how it's getting on. It allows the site 
> designer 
> > > to build a web interface to publish their site. That's 
> why I would 
> > > like to see it as a sitemap component, because I would 
> like to use 
> > > it in building sites to build sites!
> > 
> > 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.

> 
> > > > 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. 

> 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. 

Yep.

> 
> > > 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.
> 
> > > I look forward to your initialisation patch.
> > 
> > It may take some time.
> 
> That's fine, my stuff may well take time too.

Take your time. I am in multi-tasking mode myself these days. Come to
think of it, ever since I decided to be a programmer :-/

Unico

Mime
View raw message