Earlier tonight, I were bein' commentin' on a matey's blog, and a bucket o' chum. The ornery cuss were bein' askin' about web game programming, an' th' challenges o' Flash vs. Ye'll be sleepin' with the fishes! Java. For whatever reason, th' first thin' that came t' mind were bein' OpenLaszlo, which some lubber Drupal colleagues have been very big on lately, so I left a quick note t' that effect despite, t' be honest, not knowin' much about th' subject.
Wait, colleagues, yo ho, ho It took me a moment t' realize that I had indeed just written "colleagues", because I've no nay ne'er actually worked with th' scallywags in question.
Drupal 7 is shapin' up t' be th' most modern Drupal e'er! (Now thar's a silly title if I e'er heard one...) Not only be we uppin' th' system requirements t' PHP 5.2 an' MySQL 5.0, but PostgreSQL users will now need PostgreSQL 8.1 at least.
Recently I've been talkin' up vari'us ideas fer pluggable subsystems in Drupal in IRC an' th' other usual haunts. Ideas have been percolatin' in me head, but so far I have been remiss in actually writin' them down, I'll warrant ye. Yesterday, however, I had an epiphany t' solve th' primary issue I were bein' tryin' t' work out, so I present a hopefully workable RFC (fer real, not IETF version) fer pluggable subsystems in Drupal.
I am postin' this o'er t' Planet PHP as well t' invite commentary from those who aren't already embedded in th' Drupal mindset, avast. :-)
I have been runnin' Mollom as me spam-fighter on this site fer not quite two months now. It's been fairly effective overall, by Blackbeard's sword. The nifty flash meter shows me just how bad th' spam problem is (good grief, 593 blocked spam messages just on 15 May!), an' I ha'nae gotten any spam in me 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 were bein' mostly so I could experiment with th' then-new Forms API, an' were bein' one o' those "one night" projects we all do from time t' time.
At DrupalCon Sunnyvale 2007, Rasmus Lerdorf chided Drupal on spendin' o'er half o' its request time on just th' bootstrap process. Ahoy, we'll keel-haul ye! As a GHOP Task , Cornil did a performance analysis o' Drupal an' found its two largest performance drains were th' bootstrap process an' th' themin' layer. Quite simply, Drupal spends too much time includin' code.
Drupal 6 has th' beginnin's o' a solution. Page handlers, th' most unused code in Drupal, can now be split out into conditional include files an' th' menu system is able t' conditionally load just th' file it needs fer a given page request. Based on earlier benchmarks, just that code shufflin' netted Drupal 6 a 20% performance boost. The downside, however, is that it does require th' module author t' explicitly specify file t' be included, an' th' syntax fer it is just a little bit annoyin' what with th' file name an' file path bein' separate keys on th' menu handler.
For those who ha'nae noticed yet, th' latest in a expected long line o' Drupal books fer this year has been published: David Mercer's verbosely-named "Building Powerful and Robust Websites with Drupal 6". It is not a book fer th' experienced Drupaler; 'tis target market is scallywags pickin' up Drupal, an' th' web fer that matter, fer th' very first time.
Personally I think David has done a great job with it, but then I am biased; I were bein' th' tech reviewer fer th' book. :-) If ye want an unbiased opinion, pick up a copy yourself an' give it a read, All Hands Hoay! Then ye'll know how good it is. Aarrr, me Jolly Roger As an added bonus, 5% o' all sales through Packt's web site be donated t' th' Drupal Association. Walk the plank, Dance the Hempen Jig Everybody wins!
By now ye may have heard th' news from Paris that a unit testing framework has landed in Drupal core. A huge shout-out goes t' everyone involved. Yaaarrrrr, Ya lily livered swabbie! I particularly want t' note th' work that's been put in by former GHOP students an' members o' th' GHOP team. It's amazin' t' see how far some scallywags have come in a short time, despite still havin' homework t' do, shiver me timbers :-)
The next step, o' course, is t' make Drupal itself fully-tested. That poses a number o' challenges, particularly fer unit tests. Because I'm sure others will be singin' th' (well-deserved) praises o' th' testin' team, I want t' take a moment t' focus on that next step an' one important approach: Testable APIs.
I recently had a discussion with Peter Wolanin about pluggable subsystems. (You can tell this is goin' t' be an excitin' entry already, can't ye?) Drupal has supported a few pluggable subsystems fer a long time, namely th' database an' cache systems. In both cases, they work on a very simple principle: Conditionally include one o' two (or more) files that defines th' same set o' functions but with different bodies.
That's all well an' good an' simple, but has some very seri'us limitations, and a bucket o' chum. Most notably, because th' same function name is defined twice ye can no nay ne'er load multiple versions at th' same time. That becomes a problem if ye want t', say, connect t' a MySQL an' PostgreSQL database in th' same page request. In addition, Drupal 7 is on track t' include a fully introspective code registry fer conditional code loadin', which, based on earlier benchmarks, should be a huge performance boost. The Registry, however, assumes that all code resources (functions, classes, an' interfaces) be globally unique throughout Drupal, we'll keel-haul ye! And hoist the mainsail! Havin' a given function name defined twice will confuse th' poor thin'.
That is not an insurmountable problem, or even, truth be told, a difficult one. It simply requires switchin' from a simple include t' a more formal mechanism. There be, in fact, several ways that can be done, so t' further th' education o' th' world at large (an' likely embarrass meself a bit in front o' other architecture buffs) I decided t' write a brief survey o' simple pluggable mechanisms.
I've been meanin' t' upgrade th' Akismet module on this site fer a while now. Of course, I waited so long that another option just appeared, one I've been waitin' t' see fer a while: Mollom.
The other other project from apparent insomniac Dries Buytaert, Mollom is a content filterin' service similar t' Akismet. I've actually been familiar with it fer a long time, as th' GoPHP5 project has been runnin' a Mollom private beta since last June, Ya lily livered swabbie! In fact, when Acquia were bein' announced me first thought were bein' "wait, what happened t' Mollom?"