[here's a non-HTML version - mailer misbehaved again :-( ]
OT: Have you tried mozilla mail client?
* split the bean into a CocoonWrapper that handles configuring a Cocoon object and handling a single request, and a CocoonBean which handles crawling
What is the API of these new beans? Please do not forget that CocoonBean is out of the door with 2.1 release and people (might be) already building applications with CocoonBean, meaning, you can't change CocoonBean API in backward incompatible way without proper deprecating and support of released functionality.
* Made the CocoonBean use a Crawler class (derived from the one in the scratchpad Ant task)
Do you mean org.apache.cocoon.components.crawler.Crawler? I don't see how it can be used in CocoonBean. Can you elaborate?
* Moved all of the URI logic (mangling URIs etc) into the Target class
Sounds good.
* made it report the time taken to generate a single page
Ok.
Next I want to:
* moving the member variables of the wrapper and bean into a Context object, so that the Bean can be used in a ThreadSafe environment.
AFAIU, CocoonBean.processURI is already thread safe. All addTarget() methods are obviously not. addTarget() methods can easily be made threadsafe (in some sense -- call to addTarget in one thread does not break bean but affects process() running in another thread) by synchronyzing access to the targets collection. It can be thread safe in another sense too (calls to processTargets in different threads are independent of each other): you just need to add processTargets(targets) method.
* rework the way the bean is configured (possibly using Configuration objects)
Why would you need those Configuration objects?
* improve reporting so that it reports pages generated, time taken per page, the links found in a page, stack trace from errors, pages that contain broken links, and more.
Ok.
* Make this reporting use SAX (to a file), so that in future it can be the basis of a publishing service
I think that's overkill. Especially writing to the file part. Extend BeanListener interface if you like, implement FileBeanListener if you need, but I don't think SAX is really what you need here.
* Get caching working properly, and make it use ifModifiedSince() to determine whether to save the file or not.
Must-have feature. Top priority. I hope you've seen my emails on persistent store subject.
* Build a simple Ant task to replace Main.java for ant driven processes
Good.
* Make Cocoon work with an external Cocoon object, again for the sake of a PublishingService
I don't get this. What Cocoon with which external Cocoon?
* replace the contents of the cli.xconf file with correct settings for generating documentation from the built webapp, keeping the documentation system working
Don't know what you mean.
* implement exclude/include, a la Ant in the cli.xconf
Ok.
* make it configurable as to which pages are scanned for links (why generate /docs/logo.gif?cocoon-view=links)?
Set of extensions which are not quieried for the links (configuration parameter don't-follow-links=gif, jpg, png)?
* work out how to implement Vadim's idea for a single pipeline with an XMLTeePipe to generate both a link view and page view in one hit
Yep. Should increase performance and conformance!
* improve the cli.xconf format to be more flexible, e.g: generate multiple pages to a single destination, and to have links followed on some pages but not others, etc
Ok.
Phew. More than I thought! And there's more I haven't mentioned...
I'm scared! :)
Vadim
