(At BADCamp, several people were asking me to explain what the heck the Web Services core initiative was trying to do, so I got to practice my elevator pitch. This is essentially that pitch in written form.)
Drupal today is very page-oriented. Every request that comes in is responded to with a full HTML page. It is possible to return something else, and finally in Drupal 7 there is, sort of, native support to do so with delivery callbacks, but by and large any non-page response is an after thought at best and a hack at worst. The entire system is built around the assumption that we're returning an HTML page. Why else would we still load the theme system and form system for an auto-complete callback?
In the past, that hasn't been a major issue. The web was a series of pages, in practice, and Drupal is one of if not the most flexible page-generating machine on the web today. Drupal 7 is, arguably, the pinnacle of this page-oriented world.
Just in time for that world to be fading fast.
Earlier today, Dries committed a patch that adds two Symfony2 Components to Drupal: ClassLoader and HttpFoundation.
On its face it's a fairly simple patch; the new code in it is maybe a dozen lines. But it's an important part of a larger shift within Drupal to better embrace the modern web, on the server as well as the client.
This is not your father's Internet. When the Web was first emerging onto the scene, it was simple. Individual web pages were self-contained static blobs of text, with, if you were lucky maybe an image or two. The HTTP protocol was designed to be "dumb". It knew nothing of the relationship between an HTML page and the images it contained. There was no need to. Every request for a URI (web page, image, download, etc.) was a completely separate request. That kept everything simple, and made it very fault tolerant. A server never sat around waiting for a browser to tell it "OK, I'm done!"
Much e-ink has been spilled (can you even do that?) already discussing the myriad of ways in which the web is different today, mostly in the context of either HTML5 or web applications (or both). Most of it is completely true, although there's plenty of hyperbole to go around. One area that has not gotten much attention at all, though, is HTTP.
Well, that's not entirely true. HTTP is actually a fairly large spec, with a lot of exciting moving parts that few people think about because browsers offer no way to use them from HTML or just implement them very very badly. (Did you know that there is a PATCH command defined in HTTP? Really.) A good web services implementation (like we're trying to bake into Drupal 8 as part of the Web Services and Context Core Initiative </shamelessplug>) should leverage those lesser-known parts, certainly, but the modern web has more challenges than just using all of a decades-old spec.
Most significantly, HTTP still treats all URIs as separate, only coincidentally-related resources.
Which brings us to an extremely important challenge of the modern web that is deceptively simple: Caching.
My article from the inaugural issue of Drupal Watchdog is now online. Design Patterns of Drupal is based on my original session from DrupalCon Paris. Although Drupal-centric, it serves as a great introduction to the concept of design patterns in general.
If you're going to be at DrupalCon London, watch for Watchdog issue #2 in your swag bag! It looks like I may have as many as three articles in it, discussing mobile web design, Drupal 7's improved node access system, and how to approach the "Drupal stack" when planning a new site. I'll also be on stage talking about Code Smells and how to avoid stinky code, plus teaming up with Peter Wolanin to talk about what it means to work with Free Software.
See you in London!
Any time a given Drupal core development cycle is more than six months old, people start asking "When will Drupal X be released?" The answer, of course, is always "When it's ready. Please help us finish it." That's well and good, and I don't propose that we change that position. Volunteer labor and fixed release calendars do not mesh well.
However, knowing when Drupal will come out, at least in a vague sense, is increasingly important for core developers. The web is changing rapidly, even more rapidly than it has in the past, and knowing what the web will look like around when Drupal 8 is released is critical. Not only so that we can target the right features to get ahead of the curve, but so that we even know what our available tools are.
Session submissions are open for DrupalCon London, in case you hadn't heard. But what should we be talking about?
Once again, I'm going to solicit ideas from the community (that means you).
Naturally my main work these days is the Web Services and Context Core Initiative for Drupal 8. However, that probably won't be main-track session material by London, and I am already slated to present an update on that front as part of London's Core Conversations track.
In recent years, I've been developing an ongoing "Architecture Series" at DrupalCons. My intent is to help Drupalers around the world raise the bar in terms of software architecture and design. So far, I've covered:
At DrupalCon Chicago, Dries announced that the development process for Drupal 8 would be a bit different. Rather than a vast dog pile of efforts to improve Drupal in ways big and small, Drupal 8 will feature a number of major "core initiatives". These initiatives highlight major areas of work that represent not just a patch or three but major changes to Drupal's plumbing. Each initiative will have one or two initiative leads who have the ability to coordinate and make decisions relating to that initiative while working closely with Dries. In a large sense, it is a way for Dries to scale; Rather than Dries having to keep track of 1000 ongoing conversations himself, initiative owners can coordinate related changes while Dries coordinates the initiative owners. It also gives a clear indication of what work is happening and what to expect out of Drupal 8.
The first initiative for Drupal 8 has already been announced; Greg Dunlap will be leading the charge to overhaul Drupal's configuration system to provide more robust, performant, and deployable configuration and change management. That will be critical for Drupal's future as we push further into the corporate and enterprise sphere, as well as enabling more robust and unified configuration handling in the first place.
Today, I am pleased to announce Drupal's second core initiative: The Web Services and Context Core Initiative (WSCCI).
Drupal's CVS repository was pronounced dead this Thursday 24 February at 6:08 pm US Eastern Time. Cause of death was reported acute age combined with an inability to properly merge. CVS is survived by approximately 7000 Drupal projects and a new farm of Git repositories.
Pay It Forward was a 2000 romantic drama featuring Kevin Spacey, Haley Joel Osment, and Helen Hunt. Decently well-received, I found it a good, heart-warming, thought-provoking movie.
It is also an allegory for how open source works.
I've spoken a great deal recently about architectural priorities. In short, we as software developers cannot eat our cake and have it too. Improving flexibility in one area may hurt performance, while improving usability one another area may hinder flexibility. These trade-offs are not necessarily right or wrong, except in the context of the goals and purpose of the project with respect to its target audience.
But what is Drupal's target audience, and how does that impact our architectural decisions?
DrupalCon Copenhagen was a watershed event in terms of understanding how to conceptualize that question, in my view, based on conversations I had with the likes of Mark Boulton, Jen Simmons, and Sam Boyer. In his (excellent) keynote, Jeremy Keith noted that the HTML5 Working Group had a specific, defined set of priorities:
In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.
That may be a good priority order; it may be bad. That depends on your point of view and your goals. It lays out the order in which different stakeholders should be listened to, and if you come to a decision where you have to screw one group over to benefit another how that decision should be made. Having such a clear understanding of your constituent priority is critical to making good, consistent architectural decisions.
So what are Drupal's priorities?