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.
Comments
Thanks
Great interview - thanks Bert & Tom. I know that I'm guilty of poor PostgreSQL support and need to work on that for my module. The idea of different runtimes for Drupal is an interesting concept to consider as well.
runlevels
the idea of runlevels (like unix) for example running in maintencance mode, with core modules, with core modules and core themes etc... but also "single user" mode would really be a great feature I think.
--
groets
bertb
--
groets
bert boerland
AJAX performance
"In order to achieve acceptable performance with our AJAX calls, the default Drupal module loading mechanism had to be rethought."
Do you plan to contribute a patch to fix this? Let's hope so! Great work btw, the site is impressive...
---
Biology News Net
---
e! Science News
mailed
i mailed the team the procedures of getting changes back in to drupal (s modules).
--
groets
bertb
--
groets
bert boerland
Secure pages, and Actions and workflow
Tom, you indicated you needed some pages to be done with SSL. Have you looked at the securepages module by Gordon Heydon?
We are going to use it for hosted CivicSpace for all forms with passwords and private contact data. Also, you indicated you wanted workflow, did you try the actions and workflow module to move nodes through an internal workflow process? We are using it to manage support requests internally.
If you are looking for some support regarding the Javascript loading mechanism we would be wiling to commit some engineering resources to supporting that getting into core.
Cheers,
Kieran
CivicSpace
Kieran Lal
Just my two cents on the
Just my two cents on the workflow thing, that is 'a' solution but if you consider a use for an online magazine or similar content where editorial control is necessary it doesn't work well.
The reason I say that is because the only way you could do that is by having the node be unpublished and using workflow to get it through the process. (If there is another way to do that I'd of course be interested - I've got a possible future project in mind on the horizon and have thought a lot about this) The problem with that is that you need to give any users which are expected to deal with the node the administer node permission which IMHO is way too powerful to just hand out to anyone and if someone really wanted to they could just publish the node and skirt workflow altogether. Furthermore there is nothing really built in to serve as the "desk" which these things should land on. You'd have to build something or go the low tech way and query for them using the content search. The low tech way works if you've got one person with a given responsibility, but what if you've got a team of editors and you want to know what pieces are being worked on (and by whom) and which are unassigned.
I'm of the opinion that Drupal is not well suited to this purpose yet because no one has built anything to do it. If people are interested in doing that I think that systems like bricolage should be looked to for ideas on how to do it the right way. For example check out their workflow solution. That's very close to what I'd consider the perfect way to do it and it is what any kind of newspaper, magazine, etc would need.
Then there is the separate issue of administer node being way too powerful and I firmly believe that some things need to be split out of it or at the very least be able to be done separately.
As further proof of Drupal not serving the needs of that market look at some of the sites that use Bricolage. A good majority of those are media entities - eWeek, Macworld, etc. The only big news publication I'm aware of that uses Drupal is The Onion and who knows what wacky stuff they had to do to fit their editorial process.
===
BuyBlue.org | The Blue Fund | Lullabot
hehe Who knows if they even
hehe Who knows if they even use an editorial process at The Onion. Doesn't anything make it? ; )
Field level access permissions
I think a solution to this problem will be easier to build in 5.0 now that we have field level permissions.
- Robert Douglass
-----
Lullabot | My Drupal book | My Digg stories
The reason I say that is
I don't know that the node has to be unpublished. If your site is crafted such that users can't simply access unlinked nodes without knowing the nid, and especially if you just disallow user access to URLs beginning with "node" and make them always use aliases, then don't give "unpublished" nodes aliases, you can work around the published/unpublished bit.
My problem with workflow is that it doesn't explain how it actually behaves. I'm too busy to go reading the source every time I want to know how to use a module. :)
Wohoo
Amazing site. Thank you for the interview.
--
Creativine: Brands coming alive as Drupal themes
A Powerful CMS
It's good to see Drupal working with a five server infrastructure, it really shows how solid the application is.
I agree with Tom about the "to node or not to node" question. Writing my latest module, for selling ebooks, I found myself asking "should each payment transaction be a node?". My answer was no based on the fact that nodes should be just content that is visible to visitors but it would be great having some guidelines about what should or shouldn't be a node.
The great thing about big sites, such as Jump.tv, moving to Drupal is that more programmers get involved in the the community and we all get the benefits when they commit some new code or suggest improvements.
Best of lucks for Tom and his team and thank for trusting their site to Drupal!
Alexis Bellido
Check out my Drupal site for teleworkers.
I too agree that Jump t is
I too agree that Jump t is the world's leading destination for online television. This site has the best features as modularity and scalability. Drupl is still ruling in the web development..
Regards
Jennifer Lengvet