Upayavira wrote:
>
> On 27 Jun 2003 at 9:34, Unico Hommes wrote:
>
> > If I can make it that all parts of the system can share the same
> > Cocoon object then I would definitely prefer that. Because
> apart from
> > memory, there's also the cache that is shared.
>
> Presumably you're referring to a cache in a transient store?
>
> Let's discuss this in a moment...
>
> > I don't think it is necessary to make it thread-safe
> though. Once we
> > factor out the Cocoon creation code CocoonBean would become a
> > lightweight object.
>
> Yup. But again, it might not be that hard to make it thread
> safe. Presumably just an object passed in that contains all
> of its configuration information.
>
> > > Otherwise we work out a way to get hold of the Cocoon instance of
> > > the servlet.
> >
> > Perhaps CocoonServlet could put it in the application
> Context object.
>
> Let's wait until we've worked out what kind of component
> we're talking about - then we can decide how that component
> gets hold of its Cocoon object.
>
> > > Okay. So the bean needs to log to a particular logging
> category what
> > > it is up to, so that you can tell whether it succeeds or not, and
> > > then return to the next sitemap component (as SAX events)
> either the
> > > results of the page generation (if done
> > > synchronously) or the fact that a request was
> successfully made to
> > > the bean (if done asynchronously).
> >
> > Sounds good to me.
>
> Great.
>
> > > > > I would say there's two sides to the approach I would
> > > > > recommend: small steps, and keep it compatible where
> > > possible. Let's
> > > > > identify small ways we can get the functionality we
> want, whilst
> > > > > respecting the interfaces that others are quite possibly
> > > using. So,
> > > > > what first small steps would assist you in your work?
> > > >
> > > > Well, I'd like to use CocoonBean for publication runs, but
> > > I want to
> > > > reuse Cocoon instance. So as a start I think adding a
> > > constructor to
> > > > CocoonBean like you proposed would be a good start.
> > >
> > > Great. Send me a patch and I'll commit it.
> >
> > OK. I'll also have to rearrange initialize() for that because some
> > stuff still needs to be executed either way (run related stuff) and
> > some stuff shouldn't (Cocoon creation stuff).
>
> That's stuff I've not personally touched. Can't say I really
> understand it all, so I'm glad you're prepared to do it!
>
> > I don't agree that sitemap components are the way to go. Of
> course a
> > set of sitemap components requires minimal or no changes to Cocoon
> > core components and provides a lot of familiar plumbing.
> But the fact
> > is that it's an awkward arrangement of responsibilities: Cocoon
> > manages and runs sitemap components that in turn (manage and) run
> > Cocoon.
>
> 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 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.
>
> For poor people, they can stick the Cocoon site on an ADSL
> line, and have it publish to a proper web server. Multiple
> authors can upload content and publish it, and the world sees
> a decent web server.
>
> > > (I've got some code (that doesn't yet work) that'll make the bean
> > > only generate pages that haven't changed. That'd make the
> publishing
> > > service even more powerful if we can get it working).
> >
> > 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.
>
> 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 look forward to your initialisation patch.
It may take some time.
Unico
