[Typo3-dev] Welcome back in the "goto-age"?

[Sven Wilhelm]

Replies from Mathias Schreiber:

 > xclassing as one example. extending extensions and extending the
 > extended extension.
 >
 > Do the developer not want to work together?
no, they don't.
Most "developers" publicize extensions as marketing material, not for 
contributing to typo3.

 > Could many of the "enrich the core with expected
 > functionality"-extensions not move the functionality to the core?
nope, because right now to quality of the core goes first - then features.

 > Who has an overview of all the side-effects coming with this kind of
 > developing?
noone does :)

 > As I'm an admin on unix-technics for many years now I often remember
 > the  kiss-statement (Keep it simple, stupid), and you often have a
 > very transparent system in front of you.
 > Many parts of typo do not follow this statement at the moment.
and most likely never will.

 > For new users the first investment is very high.
 > As a developer it's nice for developing fe-plugins as you have the
 > final solution very fast, but coding in the backend? Use libraries for
 > ways other than the webbased way?
um.. cause typo3 is a web based system?

 > Are there sometimes reviews of the codebase? Are there release or
 > milestone plans, where you now what is currently on the topic list or
 > eg. if there is a reengineering for a subsystem planned? Has sometimes
 > the benefit to have a codebase which is smaller and faster, eg. direct
 > integration of "Authentication Services" (which in my eyes is just a
 > php-implementation of the wellknown PAM-System) to the core, not using
 > as an extension.
Kasper has high thoughts about backwards compatibility.
maybe this might answer like all of your questions at once :)

 > Is there really a need to reach the 100% flexibility? Other software
 > systems also have restrictions? Isn't the Eclipse-way just a nice way?
Dude, sorry to tell you, but you are OBSESSED by eclipse. Consult a 
doctor ;-)

 > You have defined Extension points and Extensions which use them for
 > connecting additional features. It's clean and documented due the
 > xml-file in the plugin.
I don't know eclipse but what's different from extensions in typo3? 
(except it does not use XML)

=========================================================================
 From Michael:

 >> xclassing as one example. extending extensions and extending the
 >> extended extension.
XCLASSING makes sense in many cases, but it's definitely bad to depend 
on it for long-time solutions.

 >> Do the developer not want to work together?
That's the point! Yes I sometimes get that feeling.
I really hate these "Extended __blabla-extension__" extensions. This is 
hard to understand for end-users and it puts a bad light on TYPO3.
But how can we solve that problem?

 >> Could many of the "enrich the core with expected
 >> functionality"-extensions not move the functionality to the core?
I once collected a list of such extensions. I'm still planning to 
integrate nested_feusers into the core (didn't start yet but already got 
some great support by its original author). There was one other 
extension which I can't remember right now. I will put both into 3.8.0 
if the weather stays so bad these days...  ;-)

If you know more of these extensions, please give me a little list, or 
far better, write patches!  :-)
However we should always ask the original authors if it's ok for them
(should be) and if they want to help to work on this.


 >> As I'm an admin on unix-technics for many years now I often remember
 >> the kiss-statement (Keep it simple, stupid), and you often have a
 >> very transparent system in front of you.
 >> Many parts of typo do not follow this statement at the moment.
Well, so let's start to collect these things (Wiki page?).


 >> Are there sometimes reviews of the codebase? Are there release or
 >> milestone plans, where you now what is currently on the topic list or
 >> eg. if there is a reengineering for a subsystem planned? Has
 >> sometimes the benefit to have a codebase which is smaller and faster,
 >> eg. direct
 >> integration of "Authentication Services" (which in my eyes is just a
 >> php-implementation of the wellknown PAM-System) to the core, not
 >> using as an extension.
Not yet.


 >> Is there really a need to reach the 100% flexibility? Other software
 >> systems also have restrictions? Isn't the Eclipse-way just a nice
 >>  way?
 >> You have defined Extension points and Extensions which use them for
 >> connecting additional features. It's clean and documented due the
 >> xml-file in the plugin.
We could improve so many things but very often this will break 
compatibility for older versions. I have no problem with this anyways, 
compatibility breaks would be easy to do, they just need to be 
documented. BTW, I (and some other people I guess) am continously trying 
to improve this situation (in fact, convincing Kasper ;-)).

Chances are good that TYPO3 4.0 will be the big milestone where we can 
get rid off some compability drawbacks.