JumpTV is -according to itself- "...the world's leading destination for online television" It offers nearly 200 channels from more than 65 countries, and it recently switched to Drupal! In a short interview we asked Tom Herman why they choose Drupal as their platform of choice and what caveats they found when migrating their old site to Drupal.

Drupal: Congratulations on your new site. It really looks good!
Tom: Thanks, we have put lots of work in it and we are pleased as well.

Drupal: So why did you choose Drupal as your platform?
Tom: We were looking for a flexible framework that provided us scalability, rapid development, and to the ability to reduce the need to code basic web site management features. We have always used as much open source technology as possible and after a comparison of the various tools, Drupal seemed like the best choice.

Drupal:How would you describe the benefits of Drupal compared to other CMSes?
Tom: We short listed a number of products and reviewed the source code. We looked for architectural abstraction, modularity, and scalability. We looked at the availability and quality of developer documentation, and the activities taking place within the developer community. Rapid development, themes, user management, and the active and large community of Drupal users and developers. These criteria make that Drupal stand out from the rest.

Drupal:So what didn't you like about Drupal, what were the caveats you found?
Tom: As a CMS, there is a temptation to turn everything into an node, but this isn't always an ideal solution. The "to node or not to node" question needs to be addressed in the documentation; there needs to be clear architectural guidelines outlining when one should create a node.

The second major caveat we have is that it is hard to stay on the Drupal roadmap once you start writing custom nodes. We have had to make a number of changes to users, nodes and the like. Staying on the upgrade path will take some effort.

The most obvious functional drawback is that there is no real systems for managing a content publication workflow that allows employees to create written content and managers to subsequently approve and promote that content to the production web site. This would be an obvious functional requirement for most CMSes. We like to support the development of this for inclusion in Drupal open source.

Also, many modules were not PostgreSQL friendly and some porting was required. Some modules (and this includes in Drupal core) had incorrect SQL which seemed to artifacts of a direct MySQL port. We would like to work with the community to get our changes being committed.

In order to achieve acceptable performance with our AJAX calls, the default Drupal module loading mechanism had to be rethought. On a typical page the load+parse time amounted to 50% of the total time spent servicing the request. Most of this was in common.inc which automatically loads all enabled modules. Instead, we'd prefer a run-level scheme that would allow asynchronous calls to include less functionality then a typical index.php request. For example:

Run-level 22, includes DB access, theme functions, and forums module and nothing else.
Run-Level 23, includes DB access, theme functions, blogs, dashboard and nothing else.

Finally, it would be nice to have a level of indirection around links so that we could redirect pages to SSL required links. A parameter to l(..) or similar function could be used to denote a link to a page that will transition to https, or alternatively something could be added to node to force rendering of the node through SSL only.

Drupal:Could you give us some insight on the setup of your current infrastructure?
Tom: JumpTV is running its web site on a tiered layout. As a database we use a cluster of 2 servers with 8GB RAM running Postgres and Slony on SuSE. As the frontend, we use 3 load balanced servers using an appliance, each server has 4GB RAM.

We wrote our own caching scheme and are now experimenting with memcached. We now have extensive experience in benchmarking and tuning Drupal. We'd like to see however a swappable "cache" mechanism that can use memcache/files/db/shmop/etc. The site supports thousands of concurrent users. We need to dramatically increase this as quickly as possible.

Drupal: Could you give us some insight in the timeline? How long did it took you to migrate to Drupal?
Tom: The decision to use Drupal was made in February and the launch of our site took us 7 months. We think it is running fine now but we are still looking for engineers with Drupal experience.

Drupal: Thanks for your time, and thanks for using Drupal!
Tom: And our thanks go to the community.

So there you have it, another big site moved to Drupal and is very pleased with it.