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.
> > > 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). 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.
> > 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.
Regards, Upayavira
