[TYPO3-ect] Final goal of the new framework ?

[Michael Scharkow]

Jean-Baptiste Rio wrote:
> Hi list,
> 
> I'm following all the threads in this list, and i'm a lot disturbed. I 
> try to see how the new framework will find its place in the Typo3 galaxy.
> 
> I see two ways :
> - It aims to be an alternate way to build extension
> - It aims to be the new standard for extensions
> 
> The first way seems to me ok... I would say, why not... :)
> The second way frightens me. I agree that's sometimes it's easier to 
> build new concepts instead of reusing the old ones. But i also think to 
> my bunch of extensions, and i wonder myself if i will have to rebuild 
> all of them, first of all to make my sites work with the next version of 
> Typo3 (4.5, 5.0, ...) and secondly to enrich the community extensions 
> with my work.

Funny enough. Only the possibility of creating something new brings up 
the old and much-feared Holy-Cow-of-Backwards-Compatibility ;)

The TYPO3 3/4.x branch is more than half a decade old, and the extension 
concept is almost as old. Until now, every possible workaround and hack 
has been used to support everyone: those who have ancient PHP and MySQL 
versions, those who have broken OS or webservers (hi IIS!). Same for 
extensions: Basically any 3.5 extension still works and even now we 
don't enforce CGL-compliance or DBAL-compatibility (which I tried really 
hard to establish in TER2, in vain...).

> I agree that some improvements have to be made in the current extension 
> concept but, when i look at the tons of extensions in the TER, this 
> concept seems to work and to be easy to understand for Typo3 community 
> (thanks, also, to the kickstarter team :)). Ok, not all extensions are 
> correct nor interesting. But not all extension are in the TER too.

I still maintain that 90% of all extensions are either useless, obsolete 
or insecure, or all of that. But that's not the point: While I don't 
necessarily think we should break compatibility with old extensions, I 
am not willing to write any more crappy workarounds, add tons of glue 
code or do other stupid things only to provide compatibility with 
current extensions.

> I'm not against the new framework concept, i'm just wondering if you 
> have thought to all consequences in terms of works, backwards 
> compatibility, product stability, etc... if you decide to make it the 
> only one for extensions or if you decide to change the structure of 
> extensions (see "Zend style extensions scheme").

1. Screw backwards compatibility: Anyone who still likes the XCLASS 
hell, the GLOBALS['foo'] inflation, the weird includeonce and require 
statements and various mysql_bla() calls is invited to maintain and 
develop the 4.0 branch until GNU HURD comes out or the end of time...

2. The basic extension *functionality* is not touched at all by the new 
approach, so in the *worst* case, you'd just move some code around and 
everything will be fine. I see this actually as a good thing because we 
can finally enforce compatibility with DBAL and the CGL.

3. For now, the structure changes only within the extensions, and the 
controller classes are just additional to the TYPO3 core. So even though 
compat breaks are allowed in 5.0, it will be an incremental change with 
new/updated extensions using the new APIs.

> Last but not least, i've seen that SOAP integration is planned for Typo3
> 5.0 (roadmap). Why not build the new extension concept as Typo3 Web 
> Services ? It will have many advantages without the disadvantages of the 
> extension manager rewriting.

The MVC approach has basically nothing to do with web services. I 
personally dislike SOAP as it has too much overhead and 
specificationisms. For now, we will build the new extensions with their 
own libs (so they are "statically linked"), then get the libs into the 
core and then see what's happening.

Greetings,
Michael