cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject RE: [RT] The future of our lifecycle extensions in 2.2
Date Thu, 08 Jan 2004 15:51:25 GMT

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?

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.

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.



View raw message