So we're a month away from DrupalCon DC 2009, and although the official schedule has not been published it seems likely from the preliminary schedule that my Objectifying Drupal session will be accepted. The basic idea is to help Drupal's mainly procedural army of developers get up to speed on object-oriented development, which has been gaining popularity in contrib (most notably the Views module) and will be in many parts of Drupal 7.
Of course, given how large an army of developers we have there is no one level of existing expertise I can target. There are entire multi-course college programs on OOP design, and I have an hour. :-) So, how about some preliminary feedback? What do you want to see in a one hour session on object-oriented code in Drupal?
As Drupal gets bigger and bigger in the marketplace, it is moving into areas where system administrators still hold sway. Dedicated servers or server farms have a different set of needs than a shared host when it comes to monitoring and performance.
That's not even Drupal specific. For any high-end web app, it's useful to be able to interact with it for administrative purposes through standard system tools. On Windows, that's the Windows Administrative Tools or IIS. On LAMP, that could be a unified web app like webmin or a KDE control panel plugin or a Gnome applet. Getting a web app into certain organizations requires offering existing sysadmins a way to integrate it into their existing management workflow.
But what pieces of the app do sysadmins want in their existing admin tools? Calling all sysadmins, what do you want from us? :-)
Drupal has a very aggressive caching system. While site admins can disable the page cache or CSS compressor very easily, many other caches are not so easy to disable. Think of the menu system, or the theme system, or filter content, or any number of other things that get cached.
In a production site, that's exactly what you want. No Drupal site would be able to handle even moderate traffic if every single registry cache had to be rebuild on every page load. For development, however, it can frequently be a huge pain to have to clear the cache every time you're trying to track down a bug in a menu definition or a CCK field definition.
There's an admin button to clear the cache on the Performance page, but it's not all that useful for intensive debugging. The Devel module (which you are using, right?) offers a handy "clear cache" button, but that doesn't always work if you're, say, debugging a form submission. Fortunately, Drupal makes it easy for us to disable those caches, too, although not through the admin.
Back when Drupal 7 development opened, our database layer was in a sorry state. Based on PHP 3-era concepts it offered few features, but more importantly no one actually cared about it. On rare occasions we had a PostgreSQL maintainer for the PostgreSQL driver, but they had a tendency to disappear into the Interweb, never to be heard from again.
Boy what a difference a few months make! Not only is the new database layer moving along with a good head of steam, with an order of magnitude more features and now three database drivers in core, but as of earlier tonight we officially have no less than five people on the database maintenance team. From MAINTAINERS.txt:
Via Planet PHP comes this interesting tidbit from Markus Wolff, the original author of PEAR LiveUser. After briefly lamenting over-engineered ACL (access control list) systems in PHP, he talks about a much simpler concept that holds some interesting nuggets of joy. Might Drupal benefit from some of them?
Oy, what a year 'tis been, ye scurvey dog! Aside from th' excitement o' th' election an' th' economy, 'tis been an excitin' year fer me in th' professional realm. (Personal realm, if ye dern't already know then ye shouldn't know. :-)) And o' course, 'tis been a crazy crazy year fer Palantir, too, but in a mostly good way.
Let's see, one new job, two new Drupal jobs, two conferences, one sprint, three camps, six new colleagues, two foreign countries, eight other US states, one book.., with a chest full of booty. an' a partridge in a pear tree, likely, ya bilge rat! Oof!
Via Planet PHP I stumbled across this article decrying Singletons, All Hands Hoay! It's not a new argument, really, but one o' th' comments pointed me toward a Google Tech Talk video entitled "Global State and Singletons". To be honest I dern't agree with everythin' said in either th' article or th' video, but both be spot on about th' problems o' global state, somethin' I've lamented before in relation to testing.
That is especially relevant now, as we consider th' question o' Handlers in Drupal, Avast me hearties, on a dead man's chest! Why? Because th' most controvercial part so far, th' environment variable, is designed t' address exactly this problem, a problem that is currently prevalent throughout all o' Drupal.
Permit me t' explain.
Unless ye've been livin' under a rock fer th' last six month, ye should have already heard about Drupal 7's new-and-shiny database layer, DBTNG. That were bein' only th' beginnin', though, and a bottle of rum! Much has happened since then t' th' database, an' thar's much yet t' do, with a chest full of booty. That's where ye come in...
Some time ago, I posted an RFC for pluggable "system handlers". It generated a fair bit of feedback, nearly all of it positive. That was followed up with a presentation in Szeged, which generated even more positive feedback.
So what's happened since then? Well, a fair bit. There's working code, but there are still some key gotchas to sort out. That gives us a couple of options for how to proceed, for which I would like feedback, particularly from core developers and maintainers. (Dries, webchick, this means you! :-) )