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.
I, for one, don't.
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.
But I would like to be able to build cocoon without them and prevent people with the ability to use them to solve their problems. Just like Carsten wants to do with the flow or XSP.
- 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?!?
Yes, tricky. I wonder how useful instrumentation is given that java 1.4 has pretty damn serious remote debugging interfaces.
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 ...
it doesn't matter where we put it, but how we do it.
removing actions and the flow is just a matter of moving classes and patching the treeprocess configurations. xconftool can be used for that.
removing XSP and the compiled language components can be done by moving them and patching the configurations with the xconftool
I don't know about the servlet dependency.
I have no idea on the instrumentation since we might require to 'aspectize' our code and this means java pre-processing and I don't think I like this approach. What about virtual AOP thru proxies? but that should be something done by the classloader, I think...hmmm.
