Stefano Mazzocchi wrote, On 14/03/2003 10.31: ...
First of all, there is a major architectural difference between moving the portal-framework into a block and moving flow into a block. Why? because the first is 'on top' of cocoon, the second is 'in cocoon'.
Nicely worded. I agree.
Now, I agree with Carsten that there are people that don't like some of the cocoon functionalities and would like them removed.
Yes (this is the need we need to solve, let's look at the solution)
So, since these are RT, let us say that we have:
- blocks -> things that implement functionality on top - modules -> things that add functionality inside
why this difference?
Because I expect the number of blocks to grow wildly in the next few years, but I DO NOT want to see modules grow wildly or this will only reflect on poor ability for us to define, document and validate them.
Here it is. It's the same conclusion we had come to some time back, but now things are more clear and IMHO the time is more "right" now.
- o -
So, how do we do it?
Ok, let's see them one by one:
- people use cocoon in a non-servlet environment and would like to see all servlet hooks removed
See the thread (In)Dependence on servlet, IMHO it's big enough to want a separate thread.
- people don't like/use XSP and would like to see dependencies on java compilers removed
Agreed. Now that the sitemap is not compiled, it makes sense.
- people don't like/use the flow and would like to see support for it removed
Ok.
- people don't like/use actions and would like to see support for it removed
? I regard actions on par with all other Cocoon Sitemap Components. They are part of our basic sitemap contract IMHO, I would keep them in, also because it does not bloat Cocoon or add additional dependencies.
- people dont' like/use the avalon instrumentation and would like to see support for it removed
This is tricky, Instrumentation is an "aspect", and thus cannot cleanly be separated ala OOP. How do we do this?!?
All the above can be done, but a question remains: how do we physically manage them?
That is, I propose the we simply compile them as the blocks are compiled now, with explicit dependencied and needed jars, the compilation exclustions, and samples...
Shall e have a .src/modules/** hierarchy?
./src/modules/flow ./src/modules/servlet-environment ./src/modules/cli-environment ./src/modules/bean-environment ./src/modules/instrumentation ./src/deprecated <-- move it here for consistency ...
-- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
