On Friday, Dries merged in the first major work from the Web Services and Context Core Initiative (WSCCI). In short, it means we are now making use of all of the Symfony2 Components that we've pulled into core in the past few months.
It is also step one in the biggest change in Drupal's design since Drupal 4.7.
The "kernel branch" lays the ground work for the remaining efforts of the WSCCI and SCOTCH initiatives.
menu_execute_active_handler(), delivery callbacks, and the PHP superglobals have now been replaced by Symfony2's HttpKernel, Request and Response objects, and Event listeners.
What does that buy us? Immediately, not a great deal. This is foundational work that enables all of the follow-up work of both initiatives. It establishes the basis of a new flow for Drupal's bootstrap and page handling. Really, as of today we are not doing page handling anymore; we are doing request handling. That is a very subtle change, but from a web services perspective is critically important. Pages are just one type of request.
The next major line of work is a new routing system, built off of Symfony's Routing component. The new router will allow modules to map incoming requests based not only on the path, but also on whether the request is a GET or POST, whether it's HTTP or HTTPS, and even the mime-type, allowing us to serve HTML, JSON, PDFs, and more from a single URL. Work on that has already begun and will be released as soon as possible for public completion.
Meanwhile, as I write this I am on a plane to Paris for a 3-day sprint hosted by Commerce Guys and partially funded by Acquia's Office of the CTO. The plan is work on the format that will be used for exporting Drupal entities as web services, to disk, or anywhere else. This process is the meet-point of the Web Services, Content Staging, and Entity API efforts within Drupal, and I'm hopeful that we'll be able to make significant progress toward the goal of making it dead-simple to import and export content from Drupal sites to mobile devices, other Drupal sites, client-side applications, and other uses that haven't even been developed yet.
I will also be speaking about these ongoing efforts in less than a week at Symfony Live Paris, the Symfony community's main developer conference. If you haven't gotten a ticket yet, I believe there are still a few available. Come help make this partnership even stronger.
It's not been an easy process to get here, and the hard work is far from over. I want to take a moment to give a shout-out to everyone that's helped out on the kernel work with code, reviews, architecture input, and bug squishing (alphabetically):
(And if there's anyone I missed in the above list, sorry! It's been a big group. Let me know and I'll correct it.)
There is still plenty of work to do! If you want to help right now, there's a good-sized list of Kernel follow-up issues that need attention. They run the gammut from Novice-tagged to "I don't know how this will work yet but we need to figure it out". Feel free to stop by #drupal-wscci in IRC if you have questions and a member of the team will try to help you out and turn you into a member of the team. (One of us...)
There is also on-going work to replace Drupal's session handling with the newly-improved Symfony2 session handling (improved specifically so that we could leverage it), rewrite the Drupal installer with its own small kernel implementation to make it no longer the red-headed stepchild of Drupal, ongoing efforts to clean up Drupal's classes to use PSR-0 so that we can simplify bootstrap even further, and of course the Blocks and Layout Initiative (SCOTCH).
There's no shortage of work that needs to be done yet to make Drupal 8 kick ass, and the time to get involved in the ass-kicking is now. I'll see you in the issue queues.