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

[Ries van Twisk]

Sven,

you made me cry!!!!!!!
I have been talking about exacly this with my collegue for months now...
You can do the most cool things with it...

Ries

>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 :)
>  
>
You made me really cry with this one... This is what we need and what a 
REAL CMS needs as a core.
I already did put some of my ideas down on some napkins...

>
>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.
>  
>
This is aplso on my napkins...
The fact is that we need to think about a extreemly light core that can 
handle modules.
See it as a electronic system. We have a databus and connected to the 
database we
all sort of modules. I have digging myself some time ago in the QNX 
kernel (www.qnx.com, It's an RTOS).
They follow a strict method of how modules work. We can follow such 
principle in a CMS aswell.
Sven properly knows what I mean...

>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.
>  
>
 From the beginning I found this really problamatic. Even on typo3-dev 
we cannot ask any
extension developments (but has been done) because it's a so-called CORE 
list.
This leaves 'us' extension developers to nothing. On typo3-english it is 
mosly
Typoscript, templating and extensions (not development). Developing a 
exension
is differcult in th beginning to understand how/why. There is no real 
place to ask for 'us'.

>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.
>
>  
>
Yes it is.... but this is extreemnly good reading stuff... well done! 
(still crying...)

>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.
>  
>
Yes it is... I truely love your ideas.....

>========================================================================
>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.
>
>_______________________________________________
>TYPO3-dev mailing list
>TYPO3-dev at lists.netfielders.de
>http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
>  
>


-- 
Ries van Twisk
Freelance Typo3 Developer
=== Private:
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/
skype: callto://r.vantwisk
=== Work:
email: ries at livetravelguides.com
web:   http://www.livetravelguides.com