Quote:
I feel we are making the same mistakes over and over again.
OK, John, you feel very strongly about the Framework, and I respect it.
So why don't we do that way that you suggested in your other message. Why don't you create this Framework, following 'development cycle' that you've mentioned:
1. Initial planning.
2. Planning:
3. Requirements.
4. Analysis and design.
5. Implementation.
6. Testing/Deployment
7. Evaluation and then back to the start of the cycle.
Please provide a roadmap/schedule and deliverables for each phase of the project, so we know what can we expect and when.
I also assume that you would engage authors of the other Frameworks to make sure that we have a good and solid Framework, that will be supported by the majority of the module developers.
Is it fair enough? Are you up to the challenge?
I think, once you show the analysis and design of the Framework, when you show the code, and a working example of a module, it might be easier to convince people that this is the right way to do it.
The one issue that we'll be facing is that on one hand you want to add a module framework to the core, but on the other hand people want to keep core "lean and mean", without any extra "fat". How should we merge those two conflicting requests? What if somebody doesn't want to use your Framework, but wants to use his own, or just the API directly? Why should we force that on him?
Adding a lot of code to the Core will create tons of dependencies and higher complexity, and higher chances to break things.
And how do we handle changes in the Framework, if there are no changes in the Core? Do we release a new version of XOOPS each time we make a change to the Framework. Will then people have to reinstall XOOPS every time it happens?
I think, we need to have something concrete, to touch and feel it, and to test it, in order to have better idea of the implications....
