[TYPO3-50-general] Re: [TYPO3-5.0] 5.0 components - a very rough sketch

Dominique Stender dstender at st-webdevelopment.de
Sat Sep 30 08:49:39 CEST 2006

Hash: SHA1

Hi Robert,

>> - - support for multiple RDBMS
> Of course - out of the box. But the abstraction will happen one level
> higher: We'll have a content repository instead of direct database access.

Sounds like the content repository is pretty much decided?

>> - - strong focus on scalability and usage in high-performance
>> environments
> yes and no. In my opinion the focus should lie on well encapsulated
> components and intuitive, well maintainable code. As a second step this
> code can be optimized for speed and the good architecture allows for
> scalability.

Well, good architecture might make scalability and performance tuning
easier but wrong decisions on certain components can also make this
> However, scalability on the data component for example will mainly be
> the job of the database.

Definatelly no: I said it at Dietikon and I'll say it again: I don't
believe the content repository will be fast until proven otherwise. It
is slow by design and I really doubt it will scale very good.

Currently Typo3 (4.x) is not the fastest system imaginable, the
repository will add extensive mapping on top. In my opinion Typo3 5.x
_has_ to be faster than 4.x to make it interesting for huge sites.
The content repository probably won't increase speed nor scalability.

We use a relational-to-object mapping approach for www.neckermann.de and
it becomes hardware-hungry pretty fast. But since Neckermann still runs
on that architecture - yes you can scale such an architecture, but it
comes with a price.

With Typo3 4.0 the buzzword "enterprise" entered the scene, right?
Well, Typo3 5.0 will probably the only global architecture change for
the next years, so I _really_ ask: Do you take "enterprise" seriously or
is it a selling argument?

If you take this seriously then IMO systems like Neckermann, Wikipedia
and Project Gutenberg should be possible with Typo3 and a reasonable
amount of hardware - I don't say you won't need clusters for that.
Typo3 5.x should be able to handle half a million products, another
million FE users and a daily amount of hundred thousand orders (yes I'm
in the eCommerce sector) along with anything else without skyrocketing
hardware demands.

Searching in multiple gigabytes of data honestly is a pain in the ass
for any database, it doesn't get better with the object-mapping approach
that JSR-170 goes. It's irrelevant whether JSR-170 provides a nice API
to the developer if the database grinds to a halt.

Its the same with JOINs. I'm sure JSR-170 provides an API here as well,
but that doesn't help the database much.

>> - - versioning of content. versioning of files maybe?
> All content, including files and everything, goes into the repository
> and can theoretically be versionized.

You'd like to put _files_ into the database? Sorry, when did this become
a good idea (database and webserver-wise)?

Bottom line: Maybe JSR-170 scales perfectly, I really don't know.

But I have a problem with strong dependency on JSR-170 _before_ this has
been tested and confirmed to be the way to go. Maybe its just a wording
problem, but Robert you don't sound like there's an alternative to JSR-170.

I have a DVD on my desk with roughly 3GB compressed texts from Project
Gutenberg (20,000 texts I believe). If you want I'll ship the Content
Repository team members a copy each for testing. But please whatever you
do: Test with _huge_ amounts of data, not just a website with several
hundred / thousand pages - thats not the enterprise world.

Building and designing an architecture that relies on unknown components
is _very_ dangerous.

Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the TYPO3-project-5_0-general mailing list