Sylvain Wallez wrote:
Carsten Ziegeler wrote:
<snip/>
So, I'm in favour of deprecating this in 2.1 now and removing it in 2.2.While I'm more than ok with simplifying stuff, we have to take great care of backwards incompatible changes.
Our version-naming scheme "x.y.z" states that compatibility should be ensured between different "y" versions. This has not been exactly the case between 2.0 and 2.1, and I fear that the more radical changes that occur between 2.1 and 2.2 will lead to more incompatibilities.
So the question is: aren't we moving towards a 3.0 release?
Or shouldn't we make more effort at defining Cocoon's public and private APIs? I made a proposal a while a go for this, based on javadoc attributes, but never investigated it further.
Should we make this a high priority task, so that we can distinguish what we consider to be Cocoon's internal from the officially supported API?
Yes! IMO this should be very high on the priority list. I was planning
to write a proposal for that. I missed your previous proposal. Do you
have a pointer?
It's here: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105766229504616&w=2
I was thinking that we could make the seperation across API, SPI, and implementations. Similar to the way they have been doing that in Avalon.
API being the interfaces clients can use to embed Cocoon into their
environment. So that would for instance be the Processor and Environment
related interfaces. SPI would include the sitemap component interfaces.
The stuff users implement to extend Cocoon's functionality. And then
provide two separate implementations of the public API: servlet and cli.
I think most users don't care about classes at this level: they just grab a class here or there and start building their own by overriding public and protected methods.
And the problem is that these classes often were meant either as internal and/or helper classes and their contracts were only thought of within the scope of a particular use, but not for extension or reuse.
This could go hand in hand with the proposed modularisation of the code.
There's probably more modularisation neccessary. For instance, what I'd
really like to see is something like XSP to be optional as well as other
stuff I am not sure would fit into a block.
Mmmh... modularisation is a different concerned, aimed at making the Cocoon core smaller. Optional components introduce their own API which also needs to be defined and compatibility ensured.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
