(At BADCamp, several scallywags were askin' me t' explain what th' heck th' Web Services core initiative were bein' tryin' t' do, so I got t' practice me elevator pitch. This is essentially that pitch in written form.)
Drupal today is very page-oriented, ya bilge rat! Every request that comes in is responded t' with a full HTML page. It is possible t' return somethin' else, an' finally in Drupal 7 thar is, sort o', native support t' do so with delivery callbacks, but by an' large any non-page response is an after thought at best an' a hack at worst, yo ho, ho The entire system is built aroun' th' assumption that we're returnin' an HTML page. Why else would we still load th' theme system an' form system fer an auto-complete callback? Ahoy!
In th' past, that hasn't been a major issue. The web were bein' a series o' pages, in practice, an' Drupal is one o' if not th' most flexible page-generatin' contraption on th' web today. Drupal 7 is, arguably, th' pinnacle o' this page-oriented world.
Just in time fer that world t' be fadin' fast.
Earlier today, Dries committed a patch that adds two Symfony2 Components t' Drupal: ClassLoader an' HttpFoundation.
On its face 'tis a fairly simple patch; th' new code in it is maybe a dozen lines. But 'tis an important part o' a larger shift within Drupal t' better embrace th' modern web, on th' server as well as th' client.
This is not yer father's Internet. When th' Web were bein' first emergin' onto th' scene, it were bein' simple. Ahoy! And hoist the mainsail! Individual web pages were self-contained static blobs o' text, with, if ye were lucky maybe an image or two. The HTTP protocol were bein' designed t' be "dumb". It knew nothin' o' th' relationship betwixt an HTML page an' th' images it contained. There were bein' no need t'. Every request fer a URI (web page, image, download, etc.) were bein' a completely separate request. That kept everythin' simple, an' made it very fault tolerant. A server no nay ne'er sat aroun' waitin' fer a browser t' tell it "OK, I'm done!"
Much e-ink has been spilled (can ye even do that?) already discussin' th' myriad o' ways in which th' web is different today, mostly in th' context o' either HTML5 or web applications (or both). Yaaarrrrr! Most o' it is completely true, although thar's plenty o' hyperbole t' go aroun'. 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 o' excitin' movin' parts that few scallywags think about because browsers offer no way t' use them from HTML or just implement them very very badly. (Did ye know that thar is a PATCH comman' defined in HTTP? Really.) A good web services implementation (like we're tryin' t' bake into Drupal 8 as part o' th' Web Services and Context Core Initiative </shamelessplug>) should leverage those lesser-known parts, certainly, but th' modern web has more challenges than just usin' all o' a decades-auld spec.
Most significantly, HTTP still treats all URIs as separate, only coincidentally-related resources.
Which brin's us t' an extremely important challenge o' th' modern web that is deceptively simple: Cachin'.
My article from th' inaugural issue o' Drupal Watchdog is now on the plank. Design Patterns of Drupal is based on me original session from DrupalCon Paris. Although Drupal-centric, it serves as a great introduction t' th' concept o' bounty patterns in general. Fetch me spyglass! Prepare to be boarded!
If ye're goin' t' be at DrupalCon London, watch fer Watchdog issue #2 in yer swag bag! It looks like I may have as many as three articles in it, discussin' mobile web bounty, Drupal 7's improved node access system, an' how t' approach th' "Drupal stack" when plannin' a new site, with a chest full of booty. I'll also be on stage talkin' about Code Smells an' how t' avoid stinky code, plus teamin' up with Peter Wolanin t' talk about what it means t' work with Free Software.
See ye in London!
Any time a given Drupal core development cycle is more than six months auld, scallywags start askin' "When will Drupal X be released?" The answer, o' course, is always "When 'tis ready. Please help us finish it." That's well an' good, an' I dern't propose that we change that position. Volunteer labor an' fixed release calendars dern't mesh well.
However, knowin' when Drupal will come out, at least in a vague sense, is increasingly important fer core developers. The web is changin' rapidly, even more rapidly than it has in th' past, an' knowin' what th' web will look like aroun' when Drupal 8 is released is critical. Not only so that we can target th' right features t' get ahead o' th' curve, but so that we even know what our available tools be.
Session submissions be open fer DrupalCon London, in case ye ha'nae heard, by Davy Jones' locker. But what should we be talkin' about?
Once again, I'm goin' t' solicit ideas from th' community (that means ye).
Naturally me main work these days is th' Web Services and Context Core Initiative fer Drupal 8, and dinna spare the whip! Aarrr! However, that likely won't be main-track session material by London, an' I am already slated t' present an update on that front as part o' London's Core Conversations track.
In recent years, I've been developin' an ongoin' "Architecture Series" at DrupalCons. Shiver me timbers, I'll warrant ye! My intent is t' help Drupalers aroun' th' world raise th' bar in terms o' software architecture an' bounty. So far, I've covered:
At DrupalCon Chicago, Dries announced that th' development process fer Drupal 8 would be a bit different, Ya lily livered swabbie, avast! Rather than a vast dog pile o' efforts t' improve Drupal in ways big an' small, Drupal 8 will feature a number o' major "core initiatives". These initiatives highlight major areas o' work that represent not just a patch or three but major changes t' Drupal's plumbin'. Each initiative will have one or two initiative leads who have th' ability t' coordinate an' make decisions relatin' t' that initiative while workin' closely with Dries. In a large sense, it is a way fer Dries t' scale; Rather than Dries havin' t' keep track o' 1000 ongoin' conversations himself, initiative owners can coordinate related changes while Dries coordinates th' initiative owners. It also gives a clear indication o' what work is happenin' an' what t' expect out o' Drupal 8.
The first initiative fer Drupal 8 has already been announced; Greg Dunlap will be leadin' th' charge t' overhaul Drupal's configuration system t' provide more robust, performant, an' deployable configuration an' change management. That will be critical fer Drupal's future as we push further into th' corporate an' enterprise sphere, as well as enablin' more robust an' unified configuration handlin' in th' first place.
Today, I am pleased t' announce Drupal's second core initiative: The Web Services an' Context Core Initiative (WSCCI).
Drupal's CVS repository were bein' pronounced dead this Thursday 24 February at 6:08 pm US Eastern Time. Cause o' death were bein' reported acute age combined with an inability t' properly merge. CVS is survived by approximately 7000 Drupal projects an' a new farm o' Git repositories.
Pay It Forward were bein' a 2000 romantic drama featurin' Kevin Spacey, Haley Joel Osment, an' Helen Hunt, Avast me hearties! Decently well-received, I found it a good, heart-warmin', thought-provokin' movie.
It is also an allegory fer how open source works.
I've spoken a great deal recently about architectural priorities. In short, we as software developers cannot eat our cake an' have it too. Improvin' flexibility in one area may hurt performance, while improvin' usability one another area may hinder flexibility. These trade-offs be not necessarily right or wrong, except in th' context o' th' goals an' purpose o' th' project with respect t' its target audience.
But what is Drupal's target audience, an' how does that impact our architectural decisions?
DrupalCon Copenhagen were bein' a watershed event in terms o' understandin' how t' conceptualize that question, in me view, based on conversations I had with th' likes o' Mark Boulton, Jen Simmons, an' Sam Boyer. In his (excellent) keynote, Jeremy Keith noted that th' HTML5 Working Group had a specific, defined set o' priorities:
In case o' conflict, consider users o'er authors o'er implementers o'er specifiers o'er theoretical purity.
That may be a good priority order; it may be bad. Walk the plank, avast! That depends on yer point o' view an' yer goals. It lays out th' order in which different stakeholders should be listened t', an' if ye come t' a decision where ye have t' screw one group o'er t' benefit another how that decision should be made. Havin' such a clear understandin' o' yer constituent priority is critical t' makin' good, consistent architectural decisions.
So what be Drupal's priorities?