With HTTP, we have a lovely Response object that not only provides a way of serializing the page to the end user, but also allows us to set the HTTP return code for the page and its mime-type, etc.
It is clear that we are not using this to our advantage with the Command Line Interface to Cocoon. The fact that we can't easily turn off error page generation for static web sites (that will integrate with stuff generated or preexisting by other tools), proves that we are not leveraging the HTTP return code to our advantage. Any Response with a return code in the 200s is good, and any response with a return code that is 300+ is bad.
If we leverage that information, we can suppress the output of pages that are redirects or simply error conditions (resource not found, permission denied, 500 style error, etc.).
Also, it is important to output the links AS IS. The fact that Cocoon CLI and Cocoon live produce different results is plain wrong. If I want my HTML file to have a .foo extension, then I should be able to do that without any problems. Currently the CLI version converts it to a .foo.html. I don't think that it should--or at the very least, it should be an option to turn off that behavior.
The CLI should be able to determine--in one pass--what the error condition of a page is, the mime-type, and the actual page itself. That would obviate the need for much of the multi-pass architecture now.
Lastly, things like different views should be accessible via parameters. The CLI sends in the Request Parameters, so it should be able to acess the results from the different views via the Request Parameters. That way the CLI version can do all it needs to do in one pass. THat seriously beats the multipass approach it has today.
What do you all think?
