[TYPO3-dev] Moving the topic of the discussion a little bit -- Based of thread "Change roadmap..."

[Sven Wilhelm]

Hi,

As you might have guessed I find this discussion very interesting.

I think the facts that are discussed here are very important but at the
moment the discussion is merely scratching the surface and thats why I`m
going to grab my pickax now  ;-) . Some things will sound heretical but
please believe me that they are only meant as hopefully constructive
criticism.

TYPO3 is labeled as a CMS. Well not only TYPO3, there are a lot of
products labeled like this - some or even many not as powerful as TYPO3.
But I still don`t regard this as a justification. I rather see this as a
goal as content is not limited to web and could also mean a billion
files in any size.

If you discuss about the roadmap, please keep an eye on this
questions/facts:

1. Storage Layer (which is not really existing)
---------------------------------------
At the moment there is DBAL, which might be able to use other RDBMS as
MySQL to store data. If you do a step backwards (unliteral) and think
about what content management means, you will get the inspiration to
integrate other datasource types as well, not by individual extension
hacks, but by a defined API that doesn't only respect relational
databases (sorry, but it's a shame to call mysql a RDBMS  :) 

At the end, and you must not be a theoretic guy (but one who has some
imagination) you will get an UNIFIED STORAGE LAYER, integrating a
general database access layer which is an important step further.

                           UNIFIED STORAGE LAYER
                                    |
              -----------------------------------------
              |         |                |            |
           RDMBS      XML Files    XML Databases      Webdav

This doesn`t describe all the possibilities this kind of layer provides
by far (I ran my head against the wall too often in the past when trying
to explain all ideas too fast), but if you think about the architecture
one moment and playing a little bit with it, you may find
out some possibilities yourself  :)  It scales veeery well :)


2. Changing the view on data (Strict usage of objects)
-------------------------------------------------------
At the moment most developers or coders (or call it like you want)
handle data stored in the database by requesting the wanted fields with
some filter and get the result as an associative array, iterating it an
pushing the content back to TYPO3. There`s nothing wrong doing it this
ways as long as you like to code and code and code.

Starting with a more object oriented view you think of data in objects,
you request the unified storage layer with some filter (or better a
filter OBJECT) and you get back a container object storing all object
references to the matching result. While some/many of you will think
that this is muuuuuch to complicated, let me say it's much more cleaner
as the current situation AND it's a lot easier for new developers to
start clean developing (it's also a criteria how easy it is for new
developers to start qualitative developing, how good to understand the
API is).

Having a unified storage layer like described above goes along very well
with (or let me say is a good base) regarding data as objects (Folder,
Article, News, User, Group, Link, Image,
...)

Thinks about the idea when objects are able to store themself to the
right datasource, maybe all you need is a news container (old style
called sysfolder) that knows the datasource to use :)

Example (an object news):
$news = new News();
$news->setTitle('Hello World, TYPO3 5.0 will rule');
$success = $news->save();


3. Cleanup or complete redesign of database model
--------------------------------------------------
If you have played around with the previous two sections you may have
changed your view/mind how and what data should be stored in the
database and which way. Having a unified storage layer, it should be
quite unimportant in which datasource which object is stored! You can
store a news item on RDBMS mysql or in XML file news.xml. To be able to
do that the complete object must have a strict model (not changing every
minute because another extension wants to add a column).
As some guys have asked for a normalization of the database schema in
the past, it is really 
necessary.

If you think a moment about what content management means (also see
section one) you see that transparent integration of data is one key
criteria. It should be as easy as possible to connect existing
datasources to a CMS. Only one fact is important: The data has to have a
system-wide unified identifier (I won't describe the "system" term now
or how I use it here, but let me say, it has an important role
 if you talk about scaling).


4. Getting a real Metadata System!!!
-------------------------------------
In the current situation databases used by TYPO3 are growing and growing
as people are thankful to store data in an easy way  :)  Working myself
on projects with a large content base I would like to have a good
central metadata system to store at least the information of the Dublin
Core Metadata Element Set. These information are partly stored today,
but in hundred different places (see section before). An also required
key feature for really large content bases is a central categorisation
of data. It's part of a good metadata system. If you think in objects
(see section 2) you will see that you have a metadata element to each
object in each revision (and under normalization an n-m mapping)


5. Developing style - The Eclipse Way
--------------------------------------
In several postings we could read that it's necessary to release to not
unsettle the users/companies earning money with typo3 projects. Other
guys answered that the philosophy of "it's ready when it's ready" it a
more safer and better way. At least everybody agrees to like the middle
way, secure release on a regular base.

To solve the problems that are standing in the way of making this happen
some say we need more developers, others say don't burn out the existing
developers or throw down the barrier for new developers. And both
parties are right :)

Why not look at and adopt the way of other projects? The Eclipse project
is able to ship extremely high quality releases on a regular base. Not
only because major players like IBM put money into the project (you can
burn an unlimited amount of money if you do things the wrong way) but
because they have a good way to develop - The Eclipse Way! (ok, and 
a community that gives early feedback, only possible due the Eclipse
Way!)

If you're interested in the way visit eclipse.org, describing the way
here would kill the posting :) But see the adopting of the way as a
chance.

5.b Splitting the project into manageable parts
----------------------------------------------
Big projects like the Linux Kernel are only manageable because they
split the whole system into manageable parts, the so called subsystems
(eg. network, scsi, ide, protocols,...).
For each subsystem there are maintainers that are specialized. They
concentrate on one part of the Kernel. With enough developers, this
could also be a way for TYPO3? See also next section.

6. Having regular code sprints
-------------------------------
A nice idea from the ZOPE project. The general problem for new
developers is the fact, that learning how a project works could be quite
a pain at beginning. Having so called regular code sprints where
people develop defined parts of the system together in a code camp (eg.
for 3 days) is also a chance for new guys (and girls :) to join. At
least everything that breaks down a barrier to start is a must if more
developers is a wish of the core team.
For a complete new core this is also possible for theoretic stuff as
people learn to abstract things if they were not able until then.

7. Dropping the frontend/backend behavior
-----------------------------------------
Having worked with TYPO3 for some years now, it gets a bit difficult to
break through the barriers of habit and find a solution for those
editors that complain about the unnecessary abstraction layer they are
forced to deal with when using the backend to edit their front-end page.
Recently I had a look at Apache Lenya and was amazed how simple a good
solution could be and why I didn`t see it myself. Frontend-Editing
(usability) should be improved in a way that the editor has an office
bar on top of his screen. This is how her/his browser works - this is
how Open/MS-Office works. 
Simple and works:
http://lenya.apache.org/1_2_x/components/layout/lenya-menubar.html

At least imagine that at the moment you see usability from a developers
point of view. But an editor has another view, he looks task oriented on
the system!!!

8. The TYPO3 Kernel and it's different implementations
-------------------------------------------------------
Not today :) You must hate enough already :)


But after all the "theoretic" stuff (I call it system-design) some
pragmatic stuff :)
--------------------------------------------------------------------
-> A good base for a more advanced database abstraction layer could be
   Propel. This project builds a Object Relation Mapper (reminding parts
   of section 2 :)
   Starting on such a base should boost developing a new base like a
   rocket
-> There are several good template systems out there. Using one of this
   existing projects will save a lot of development time. One of these
   really perfect systems is ZOPE TAL (Template Attribute Language) that
   is also implemented in a PHP Version.

Ok, so far. The described things are maybe 30% of my current stuff (in
brain) for a new possible solution. Thanks for reading until now without
throwing a knife to the heretic. It's hard to describe the ideas in
textual form as you need to get the reader to understand the way you
think in general.


A last word to the current hype of TYPO3!
------------------------------------------
It's clear to myself that I will talk about something now for what 98%
of the community will hate me after, but lettings things walk the way
theys do is much more critical and dangerous than starting a maybe angry
discussion about that fact.

I think many of you are familiar with the term ".com boom" where many of
the conservative!!! banks and consulting companies sponsored millions of
dollars into companies with dubious business plans as long as they
where IT companies. Do you start comparing something :)

It's nice that TYPO3 grows, it's nice that many companies join the
project and like it as a base for their commercial projects, but it's
very, very DANGEROUS how TYPO3 hypes at the moment, as a system itself
and the personality cult you hear very often in TYPO3 UGs!!! In such a
situation people will overestimate themselves very fast. The smaller
problem is the damage of your personal reputation (maybe not), the
bigger one is the risk of burning budgets with collapsed projects.
Nuff said, now please think about this for a minute and calm down a
little bit if necessary.

In the last years TYPO3 was used for sites where it is not ready for. As
I have also thankfully profited from TYPO3 in the past, I wanted to give
this ideas/views I made over the last years back. I did this in the past
a lot of times without success (nice to hear, but no thanks). So here
they are written down now one more time. I hope it was the right time
now.

========================================================================
A good friend of another IT-Service company told me something in the
past that was stored in my brain as a golden rule:
Grow, but grow healthy!
========================================================================

Kind regards Sven

PS: I offer my help for architectial, theoretic and practical developing
stuff. But I'm more interested in a general overhaul.