cck

Here's something I recently presented at the DC Drupal Meetup:

You've already heard us prattle on about Hey!Watch — it's a great video transcoding service that we've gotten in the habit of using for several of our clients. As much fun as wrestling with ffmpeg is, sometimes it's more appealing to just bit then bullet, pay a dime per transcode and not have to worry about keeping your codecs up to date.

They offer some neat add-on features, too, like direct uploading of transcoded videos to your Amazon S3 account. Even more tantalizingly, there's this: a method for allowing your users to upload directly to Hey!Watch's servers, complete with fancy-pants AJAX progress indicator. There's no need to spend your server's bandwidth and CPU on videos at all — you can stick to running Drupal on your system, outsourcing all the heavy lifting. You can send along your own arbitrary variables with the video submission, then receive them back via a ping that Hey!Watch sends once transcoding is complete (allowing you to keep track of who uploaded what video). It's pretty slick.

But interested Drupal developers will click through to the Hey!Watch code and despair. First, the AJAX is written with Prototype, which won't play nicely with Drupal's preferred jQuery library. Sure, it'd be possible to rewrite it in jQuery — but I'd really rather not.

Second and more damningly (and unsurprisingly), the form that uploads to Hey!Watch needs to stand on its own. You won't be able to nest it in a Drupal form — Drupal understandably doesn't like nested forms.

Any interested Drupalologist would do well to go read Jeff Robbins' take on how to improve Drupal. Okay, so it's a bit utopian — I think he's only half-kidding when he talks about Drupal "saving the world." But the guys at Lullabot know Drupal's strengths and weaknesses as well or better than anyone else.

I was particularly interested by the "What If..." section of the post. He phrases it a bit more politely, but Jeff's right: drupal.org and api.drupal.org are downright embarrassing when compared to other CMSes' sites. Providing the the code that comprises a function is not the same thing as documenting that function. And providing a boring, poorly-organized product site is no way to win converts.

For my own, selfish part, I'd just like to see some stability in the APIs. 4.7's Forms API changed everything; 5 changed much of it again. I've become a grudging convert to using CCK and Views for nearly everything — there are very good reasons for that design decision, made by developers smarter than I — but there's no question in my mind that it's made development slower. I'd like to see these projects remain in a stable place for a while, and try to consolidate rather than continuing to reinvent the wheel — the fact that CCK has its own pidgin DDL is something no one should be happy about.