Weird things happen when I travel. Like, I spend several hours sitting around in airports with nothing to do but write documentation. I am therefore pleased to announce the immediate availability of both upgrade docs and usage docs for the DBTNG system.
With the Drupal.org redesign process well under way and moving along at high speed, it's become apparent that some of the details of the "Why" of it all were never quite established. To be honest, I didn't understand the full scope of what "Drupal.org redesign" meant either until recently.
Oh, travel. I don't mind air travel, in general, but there are always road bumps.
OK, I admit it. I'm not the most active Cubs fan around. I wouldn't say I'm a fair weather fan (the Cubs don't have fair weather that often) but I don't follow the team that closely. Perhaps I should start doing so, because I think this may be our year.
No, it's not because this is the 100th anniversary of when the Cubs last won the World Series. It's because the Databases: TNG patch for Drupal 7 has finally landed.
And there has been much rejoicing.
Earlier tonight, I was commenting on a friend's blog. He was asking about web game programming, and the challenges of Flash vs. Java. For whatever reason, the first thing that came to mind was OpenLaszlo, which some fellow Drupal colleagues have been very big on lately, so I left a quick note to that effect despite, to be honest, not knowing much about the subject.
Wait, colleagues? It took me a moment to realize that I had indeed just written "colleagues", because I've never actually worked with the people in question.
Drupal 7 is shaping up to be the most modern Drupal ever! (Now there's a silly title if I ever heard one...) Not only are we upping the system requirements to PHP 5.2 and MySQL 5.0, but PostgreSQL users will now need PostgreSQL 8.1 at least.
Recently I've been talking up various ideas for pluggable subsystems in Drupal in IRC and the other usual haunts. Ideas have been percolating in my head, but so far I have been remiss in actually writing them down. Yesterday, however, I had an epiphany to solve the primary issue I was trying to work out, so I present a hopefully workable RFC (for real, not IETF version) for pluggable subsystems in Drupal.
I am posting this over to Planet PHP as well to invite commentary from those who aren't already embedded in the Drupal mindset. :-)
I have been running Mollom as my spam-fighter on this site for not quite two months now. It's been fairly effective overall. The nifty flash meter shows me just how bad the spam problem is (good grief, 593 blocked spam messages just on 15 May!), and I haven't gotten any spam in my comment list yet.
That is, until today, when a new form appeared.
Some time ago, on a lark, I wrote a Drupal module called Google Search. It was mostly so I could experiment with the then-new Forms API, and was one of those "one night" projects we all do from time to time.
At DrupalCon Sunnyvale 2007, Rasmus Lerdorf chided Drupal on spending over half of its request time on just the bootstrap process. As a GHOP Task , Cornil did a performance analysis of Drupal and found its two largest performance drains were the bootstrap process and the theming layer. Quite simply, Drupal spends too much time including code.
Drupal 6 has the beginnings of a solution. Page handlers, the most unused code in Drupal, can now be split out into conditional include files and the menu system is able to conditionally load just the file it needs for a given page request. Based on earlier benchmarks, just that code shuffling netted Drupal 6 a 20% performance boost. The downside, however, is that it does require the module author to explicitly specify file to be included, and the syntax for it is just a little bit annoying what with the file name and file path being separate keys on the menu handler.