Matthew Langham takes the stage

Possible improvements

Matthew sees three areas (suggestions freely added by notetakers based on audience reactions and discussions):

Too many choices? (eg. FormHandling, InputModules etc.)
- Publish more Best Practices?
- Have better samples, more like tutorials than just simple tests of our stuff
- Samples which are also documentation, self-explaining
- Javadoc-like documentation of the sitemap (using annotations), XSLT and maybe other stuff. Modifying the TreeProcessor to ignore an "annotation" namespace would enable this
- Tool for 'JavaScriptDoc' sourceforge or mozilla
I don't understand the error messages
- Standardized terminology for error messages?
- Sitemap-level stack traces, to know which use of which component caused the problem (sitemap line number, pipeline reference, etc)
I don't understand the logs
- I have a hard time using the log system (selecting which categories to log, etc.)
- SAX-based architecture makes it hard to find out where an error occurs
- How do I turn off logs completely, for Production?

Forrest has been good at leading beginners, after "forrest site" you get a message telling you what to do next, etc.

cocoon.xconf
Sitemaps
Relationship between Cocoon configuration and container (TomCat, Jetty, Apache HTTPD) configuration and logs

Sylvain has some suggestions:

Having default configurations in all components, so that an empty or nearly-empty cocoon.xconf would define "reasonable" defaults.
Dynamically discover components which implement certain roles to suppress the required declarations of components.
Use variable strings in .xconf files, for example for database URLs, usernames, etc.

Seems hard to implement, and hiding everything might not help users?.

But there's agreement on the basic idea: simplifying configurations.