For Drupal 8, we want to bake REST support directly into the core system. It's unclear if we'll be able to go full-on hypermedia by the time we ship, but it should be possible to add via contributed modules. For the base system, though, we want to at least follow REST/HTTP semantics properly.
One area we have questions about is PUT, in particular the details of its idempotence requirements. For that reason, I'm reaching out to the Interwebs to see what the consensus is. Details below.
Last week I was at DIG London, in London, Ontario. It's normally a gaming conference, but they've added a web track and asked me to come speak. It was a fairly good experience, helped in part by their keynote, the infamous Jeffrey Zeldman talking about responsive design and related topics.
One of the points Zeldman made was that users want content their way, not the way we (web designers, web authors, and web devleopers) want it. Visually impared users want content read to them, or resized. Color blind users want a different color scheme that they can actually read. Smartphone users want content in a narrow column, without a dozen sidebar blocks. Mobile users want content offline, so they can read it on a plane. Many users want just the content, no design, and so use tools like Instapaper to strip out everything but the text of an article. RSS feeds have been around for a decade, and are now growing rapidly thanks to mobile devices, and those are generally (mostly) layout-free. If you're doing responsive design, then you're not making a design but the framework of a design that will change, and possibly mostly disappear, under certain circumstances.
Of course, that to me begs a very important question. When I asked it during Q&A, even Zeldman didn't have an answer. (Yes, I stumped the King of Web Standards. Woohoo!)
In the modern web, does web design even matter?
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?
A few weeks ago, I and several others helped some friends of ours pack up their apartment into a truck in preparation for moving cross-country from Chicago to New York. It was, as such moments generally are, bitter sweet. It's always a good feeling to help out a friend, but when you're helping them get further away from you it's not as pleasant.
Of course, me being me, what struck me most about the whole process was how well it served as a model for software development and project management in general.
Well, it's been long enough after DrupalCon for me to survive another conference and a business trip, so I finally have time to reflect.
(See below for slides from my sessions.)
There has been some discussion in recent days regarding Object-Relational Mappers (ORMs), Drupal, and why the latter doesn't use the former. There are, actually, many reasons for that, and for why Drupal doesn't do more with the Active Record pattern.
Rather than tuck such discussion away in an issue queue, I figured it better to document a bit more widely.
According to Drupal.org, it has now been four years and five days since I first joined the Drupal community. My how time flies, and how much has changed since then.
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? :-)
One of the major changes in Drupal 6 (where "major" is defined as "worthy of a mention in Dries' keynote") was a new feature of the menu and theme hooks. The newly introduced "file" and "file path" keys in those hooks' respective retun arrays. allow them to define files that get included conditionally, only when needed. In theory, that should be a big performance boost; page handlers are virtually never called except for on the page they handle, so loading all of that code on every other page is a waste of CPU cycles. Of course, there is also the added cost of the extra disk hit to load that one extra file we need. Modern operating systems should do a pretty good job of caching the file load, but that may vary with the configuration.
So just how much benefit did we get from two dozen fragile patches that were a glorified cut and paste? And is it worth doing more of it? Let's benchmark it and find out.
For those who haven't really been following it, several hundred contributors, 13 months, and tens of thousands of lines of code have gone into making the only version of Drupal ever that is better than Drupal 5. So, naturally, we've released it and called it Drupal 6.
Drupal 6 boasts a boat load of new functionality, ranging from Ajaxy yumminess throughout the system to native support for OpenID to vastly enhanced multi-lingual support. Several entire subsystems have been either overhauled or totally rewritten to proivde more power, flexibility, and speed. The official press release has the complete rundown, or for the more visually inclined there's a new features screencast. For me, though, the new theming system is feature numero uno.