[sakai2-tcc] Annotation based injection within Sakai components

[Charles Severance]

I think that we need to avoid major non-upwards compatible Kernel changes through the end of 2013.  Small changes are OK not lets not build a whole new kernel.  OAE has done that.   As others have said, there will be so little new development in 2.x that our antique service pattern is not the limiting factor.

What people are proposing sound a lot like Moodle 2.0.   It was intended as a rewrite, an architectural redo, etc etc.   After it fell behind, they ended up not accomplishing everything they hoped and then released something which was not all that great of an improvement for end users nor all that great of an improvement for module developers.  It was just different and incompatible - not particularly better.

It took a lot of inertia out of Moodle for several years and they are just finally recovering from it.   Re-Writes take forever.

If I were to come up with things to put on a 2012-2013 roadmap it would be things like:

- Create non-SQL message pump and put it in trunk as the default

- Add id columns to AUTHZ tables and switch to all integer joins for significant AUTHZ queries

- Go through and greatly reduce the use of state from Velocity tools

- Careful performance testing and tuning in trunk

- Add multi-tenancy hooks into the data model

- Improve our test coverage for test plans, unit tests, etc

- Strengthen /direct across all tools - build a set of tests that pound /direct


I am not saying that these *are* the things to do - what I am saying is that Spring 3 is *not* the thing to do.   We need to not make the Moodle mistake and lose our contrib community in our gung-ho goal of internal cleanliness that has no end-user or system deployer impact.

In terms of OAE (I will speak carefully here), I think that 2014 will be an important year for OAE.  If OAE is still trying to get off the ground in 2014, I think that the broader community might decide that OAE has taken too long and decide that it is not the next big thing given that it started in 2008.   A rewrite that is still not done after six years and millions of dollars per year kind of proves the point. 

So from a CLE perspective I think that in 2013 we need to be tactical and then in 2014 become strategic depending on the state of OAE.  Here are some possible scenarios:

(a) OAE emerges beautifully in 2014 and is in reasonably wide production in 2014.  In that case I think we all will just start working on OAE and 2.10 will live long and propsper with a long series of non-expanding dot releases.

(b) OAE does not thrive in 2014.  At this point, we *may* decide that CLE needs to move back to a feature-expanding strategy.   If that is the case, our path forward would likely *not* be writing our own brand new Kernel or evolving the current kernel in new ways.  A *much* smarter approach would be to take parts of OAE - in particular the service model, etc and then extend it and then graft our services into it to make a super-new kernel.  I think that much of the early work in OAE w.r.t. how to make services was pretty solid and brilliant and we dont' need to re-visit all the things they tried and discarded.

Sooooo - that is a long way to say that a major kernel redo in 13-14 is not a good idea IMHO.   In 14-15 we either will be in maintenance mode or borrowing tasty bits from OAE.  So starting an effort to make a "third" kernel seems not to be a useful effort at this point.

Sorry for the long text.

/Chuck