Hi! Very nice task :D
Here is my vision, given these constraints: The next Cocoon should be boiled down to the basics most people need, and it would do what Cocoon 2 does best: XML processing. However, it would also allow for a more application-oriented (i.e. object oriented, not procedual or scripty) way of developing, using an MVC-based approach. Having said this, the next Cocoon would consist of: - Only POJOs (possibly shipping with some Dependency Injection based container, but being _independent_ of it) - Nice and consistent seperation of interfaces and implementations - e.g. sourceresolver, caching, "processor", etc. - also includes auxiliary services, like logging interfaces - A flexible plugin model (possibly uses OSGI, but more for its classloading and class visibility features) - plugins may provide new implementations of any interface in the core or other plugins - Interfaces to processing implementations, plus core-ish plugins: - A similar pipeline (possibly pull-based) architecture as Cocoon 2 (only processing, not sitemaps) - A new MVC architecture (with no limitations on the model by e.g. assumed persistence solutions) - A generic sitemap api for the processing implementations (enables dynamic pipelines, and a flexible sitemap language) - An authentication architecture which integrates with the processing architecture - A default servlet adapter for the Cocoon application This would mean a very tiny, error-unprone core, easy extensions, independence of IoC containers and their quirks, support for both great Cocoon 2 features plus new web-application oriented features and more flexible authentication. Also supports coding according to Marc's layers. Just my very own vision. max > -----Original Message----- > From: hepabolu [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 08, 2005 10:37 > To: [email protected] > Subject: Cocoon NG vision: focusing on the primary functionality > > > Guys, > > reading the threads on Cocoon NG (Cocoon X? ;-) ) I get the feeling > that, although much is said, you're more or less running around the > heart of the matter without actually getting there. So maybe > this little > exercise might help: > > What should be the first functionality of Cocoon NG if you > are allowed > to work on it only once and have to leave it in a useable state? > > More elaborate: you have a reasonable but short period of > time to start > with a clean slate. You can either start from scratch or haul in > existing stuff from Cocoon 2.X. You should deliver something useful, > i.e. solid, functional software, even if you will never be able to > revisit this project again. Yet it should be flexible/well-designed > enough to be extended/expanded should there be time and resources. > > Extra constraint: it should be compatible with Cocoon 2.X, either > through backward compatibility or through a well-defined conversion > process. If not, it should be documented why this is still useful. > > If all this applies, what is it that Cocoon NG does? > > Bye, Helma >
