[TYPO3-v4] New vs "Old" Extension Manager

[Christian Kuhn]

On 09/12/2011 10:16 PM, François Suter wrote:
> Originally Xavier started this thread to assess whether we could get rid
> of the old EM in 4.6. It's now too late for this move, but we propose:
>
> - to make the new EM the default in new installations of 4.6
> - to get entirely rid of the new EM in 4.7

You mean *old* here, right?


> There's a point where we need to make a choice. The old EM is currently
> broken in places because of some of the changes made for the new EM. The
> new EM is not working as satisfyingly as it could, because the code
> would need to be refactored far more thoroughly than it already was. As
> long as we try to keep both EMs running, we'll face issues in both.
>
> Opinions?

Disclaimer: My own opinion, it might be a bit radical ...


Thesis:
Codewise, new em does not simplify things. It is built on-top-of old em 
code and makes things even harder to maintain. The whole thing should be 
built from scratch.


Explanation:
Codewise, we have different god classes playing the game: there are 
those monster central two em classes that do the main magic, there is 
t3lib_install (which is now an least split to t3lib_install_sql), they 
are extended and inter weaved with the install tool, there is 
t3lib_extMgm. Some code is duplicated in install-tool code. Basically we 
have a real mess of non-distinguishable classes doing installation foo 
(need a bad day? read the em core code!)

The worst thing is: New em builds on top of this mess. If you change any 
code of the mentioned classes you can be sure that *both* em break, 
maintaining them is a nightmare (example: 
https://review.typo3.org/#change,4536 - this one-liner took Susanne and 
me about 4 hours to tackle).

The js and extjs direct adapters in new em are actually pretty straight 
forward and more or less simple to maintain. But there is a major 
problem with the legacy code that is used by new and old em: I've 
scratched my itch for at least 6 hours to add this simple 'get tables 
from caching framework' patch for 4.6 and solution it was still not 
perfect but issued a new patch that added two parameters for some 
arbitrary methods making the thing even more ugly.

We have even more flow in this scenario: Benni took an architecturally 
far better approach than the new em and is rebuilding the install tool 
from scratch. He is throwing away *all* old code from t3lib_install and 
tx_install, wrote a simple mvc, takes fluid as rendering engine and now 
re-implements the functionality *as is* on on a new code base. 
Unfortunately the project was not ready for 4.6, but I'm looking forward 
having it in 4.7. After this is done, the scope of the em and the 
install tool can be reconsidered and maybe we can come up with a 
solution in the long run that is based on maintainable code.

Conclusion: Either old or new em *must* be dropped, and the code must be 
build from scratch to achieve a maintainable code base that resists 
functinality and scope refactorings. Think about different 
distributions, updates in the install tool, community driven packages, 
automagic configuration for special scenarios, those things must be 
covered by em and install tool. All that leads to *major* headaches with 
current code base. I'd bet if we brainstorm we would come up with major 
different meanings of what a em and what the install tool should do at 
the end, and if we want to realize anything of that we need flexible and 
maintainable code.

At the moment, based on the current code base, I'd recommend to drop new 
em, and build a new install tool and a new em on a flexible code base. 
At least I'm personally not available to maintain new em code as-is 
because of its high 'what-the-fuck-per-minute'-factor in combination 
with the old core classes.

Realistically, I'd not change too much in new em anymore, just fix the 
most problematic UI things like you and Xavier did, maybe at best drop 
as much as possible from legacy code, but I'd not rely on anything of 
the current code base for a real solution of 4.7 or above, it is just 
too messy.


Regards
Christian