>
> -----Original Message-----
> From: Upayavira [mailto:[EMAIL PROTECTED]
> Sent: vrijdag 27 juni 2003 11:51
> To: [EMAIL PROTECTED]
>
> 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
