Technology Specification

The general structure proposed is to have four tiers of servers (although, some servers could belong within more than one tier). The four tiers of servers are: 1) Front End Servers, 2) RPC Servers, 3) MySQL servers, 4) static content servers.

Technology Overview

NOTE: For an impassioned defense of this architecture and for more information about specifics, please see the ArchitectDiscussion page.

For a rough drawing of this technology, see this - http://dev.bunke.indymedia.org/attachment/wiki/ArchitectDiscussion/indyarch.jpg

For each tier, a different technology is used: 1) Front End Servers will be Apache2, PHP5 (+APC?) and RPC client. 2) RPC Servers will most likely only run ICE (making them good candidates to also be static servers). There probably won't be that many servers within this tier -- we'll probably just need a minimum of two (for minimum redundancy). 3) MySQL servers will run MySQL 5.0 as either masters or slaves. 4) These machines only run Apache -- or even better, one of the scaled-down, optimized-for-speed web servers. Of course, there will also be a DNS tier but this should be administered by the existing Indymedia DNS group.

Technology References

1. ICE - http://zeroc.com/ice.html | ICE and Cake
2. CakePHP - Our Introduction | http://www.cakephp.org/ | http://manual.cakephp.org/
3. http://httpd.apache.org/docs/2.2/
4. http://dev.mysql.com/doc/refman/5.0/en/
5. http://developers.facebook.com/thrift/ - probably won't be used

Making the Case for CakePHP

1. PHP is, without question, the best front-end development platform for the web today. The entire language is built for web development. It is proven to be scalable as a web front-end. It has the lowest barriers to access for new programmers which is essential for volunteer projects like Indymedia.

2. This approach is a compromise. Those programmers who wish to work on Python-base projects can devote their energies to the middle tier. Those who know PHP can contribute to the front-end. MySQL experts can build the most sophisticated geographically-dispersed MySQL set up without *any* constraints from the application.

3. This approach is impervious to the loss of any single machine because of law enforcement, corporate subpoena or acts of God. Each server could be a webserver, a middleware server, a database server -- or all 3 at once depending on how much it can do! It can, in theory, be infinitely scalable.

4. This approach allows *numerous* people to participate as "servers" -- even people with home DSL, a static IP and a Unix box could join in as a server.

5. This approach is *very* light-weight. Each tier is something very simple and controllable: a webserver, or just a middleware server running a middleware daemon, or something like that.

Making the Case Against Drupal

1. The case is very simple. While it's possible that Drupal could be adapted to this architecture, ultimately Drupal is not a rapid application development framework. It offers modules and an API to deal with them, but Drupal is sorely missing all the truly amazing things that Cake offers you as a programmer. Drupal doesn't want to be a framework, but when you boil it all down, Drupal MUST be a framework in order for it to be competitive. And it just isn't that nor do the developers intend it to be. To me, this is the end of the story.

2. Modules - Drupal modules can be very attractive but can be a problem when is not supported for new versions of drupal. Collectives who have use drupal since 2002 had many problems with that, being forced to keep some sites under old versions for a long time, which also make it difficult for those sites to benefit of security patches and plugins that only run on new versions.