 or the whiskey lovers in the room. The original kind of mission statement was to transform in Drupal from a first class CMS to a first class REST server with a first class CMS on top of it, which means we need all of this fun stuff, powerful context system, context sensitive layouts, block-centric layouts, plug-in mechanism, and yet no one actually understands what that means. Bottom line, what we're trying to do is convert Drupal from a page-serving tool into a HTTP REST serving tool. And then pages are just a special case of REST. People know what I mean when I say REST. Good, most of you raised your hand. It's going to be a really brief introduction. This is a good thing. So yeah, that's basically what we've been trying to do is convert Drupal into a tier one REST server so that we can do way more powerful things at the CMS level. The original impetus, this is the way a page is built in Drupal 7. Request comes in, and we go to a page callback. We render this big content area blob or render array depending on what it returns. Then we throw this extra stuff around it called blocks that has nothing to do whatsoever with the page body. And then there's this other stuff that doesn't really fit anywhere, and that's kind of the page, and that's every single page on the site. Everything else we do to make it more flexible than that is a hack. Some of them are incredibly nice hacks, incredibly powerful hacks, but they're a hack around the way the system is built at a fundamental level. And this is great in 2002, but not in 2012. And this is the, you can see it, the kind of logic flow inside Drupal 7. Request comes in, load up a menu item, go through our menu routing system, which gets the page callback, which could get back a render array or a series of Ajax commands. We don't quite mark them separately very well. Then we call the delivery callback, which if it's an Ajax command goes through its own pipeline and then ends up with a print. If it's a render array, which means HTML usually, we go to that, go through a page build process, which then takes this big render array and throws extra crap onto it, including building blocks, which is throwing more stuff onto this big render array. Then we pass that entire thing through an alter form, which means anything can change anywhere without you being able to control it. And then we compile all of that down to a gigantic HTML string and print that. In order to do anything useful besides full pages, something like services module, steps it out and re-implements the entire system itself on top of it and has its own architecture in there and its own output point. And I haven't even gotten to panels. Yuck. This just is not sustainable. This is where we want to end up. Request comes in, pass it through some core routing system and we get back some controller object of some kind. And that renders a page response, which consists of a series of blocks inside it that get that information, get that contextual information about how a page is built, about what the information of the page is, like what node am I on? What user am I on? What is the organic group of that user? What's the language the page is in? All of this information that is really, really relevant that we don't deliver anywhere right now except for the core body of the page. Each of these individual blocks then depends only on this information passed into it, which means if each of these blocks we can uniquely address with the URL, we can fire any block as a sub-request, as an ESI request from Varnish. So we can do partial page caching in Varnish or straight in Drupal. Or we can do an Ajax callback. Any block becomes something you can Ajax replace. This is insanely cool if we can turn around our rendering system and build the page top down instead of inside, outside, alter and stuff. And this is what we've been trying to do, build the infrastructure that makes this possible. Actually implementing this picture is the responsibility of the SCOTCH initiative. They're the last session today in this room. Come back for that too, that's part two. But we've been trying to build a plumbing to enable this. And that is how we ended up with symphony. How do we end up with symphony from that? Well, I'll tell you. Originally we knew we wanted to abstract HTTP request response handling because superglobals are not gonna hack it for what we want to do. It's just not gonna work. And we said, okay, let's not write this ourselves. Someone must have written this already in PHP. We're all about dealing with HTTP. That's what PHP is for. So someone must have written this. Let's just borrow that one piece from somebody. And so we looked at a couple of different options in particular symphony two and Zend. And we ended up going with symphony two for three reasons. One, their library was a little bit more robust than Zend's. Not by a great deal, but it was a little bit nicer. Two, at the time, Zend had a contributor license agreement. So you couldn't actually submit code to Zend framework unless you signed a form saying guy, this claim copyright and patents and all the kind of fun stuff and symphony didn't. And I figured we're going to want to work upstream at some point once we do this. I don't wanna have to deal with that. I don't wanna tell people I have to sign forms and fax them in before they can work on Drupal. That's not gonna fly. And three, as we were having this discussion, several people from the symphony community came in to that discussion and offered to help and engaged with us. And those people are actually here at this conference. One of them is the keynote tomorrow, to be in Pontossier. And that kind of community interaction is something that we felt, and I in particular felt very strongly was more important than the code library itself. We're going to be engaging with this other community to some extent. We want them to be a good community. And so we went with symphony. And so we continued using that library and trying to build this inside out model and okay, how do we do this? And this part is weird and I don't actually know how we do this thing and so on and so forth. And we got kind of frustrated because we kept running into technical problems and process problems and I don't understand it yet problems. And then I started looking at some of the other pieces of symphony that we weren't using yet and said, well, crap. What we're trying to build is symphony, is how symphony's request handling works already. Open source for the win, let's use it. That's basically how we ended up with saying okay, Drupal 8 is going to be based on symphony. Not on the entirety of symphony however. Symphony consists of two pieces. There's the symphony components which are a reusable set of freestanding libraries that can work with each other but can also just live in isolation. And the first one we brought in was the HCTP Foundation library which is requests and responses and stuff like session handling tied into that and that's pretty much it. So it's a way to abstract away from super globals so that you can do more robust handling. And then there's the symphony framework which is a full stack application framework built on top of those components. We're not using the framework. So if you've worked with symphony full stack framework we're not pulling in that entire thing. We're just pulling in six or seven or so of the symphony components, the major ones and building our Drupal framework on top of that. So in particular, I think we may have gotten, did we remove that from the yet catch? Class loader? It's still symphony. Okay, so we're using symphonies class loader for auto loading classes off disk. So who here hates the registry in Drupal 7? It dies at the end of this month. Yeah, so there's a lot of work that's gone into converting over to this. What's that? Can you write it? I did write early versions of the registry. I'm very happy to see it die. HTTP Foundation, which is the request response library. Event Dispatcher, it's basically object oriented hooks and you understand Event Dispatcher. They're dependent to injection container. And most importantly, HTTP kernel and routing. We'll talk about that a little bit here. And so we end up with this hybrid system that the goal at least is it gives us all the benefit of the years of work that has gone into building this solid foundation and symphony components that then we don't have to spend years working on, but then gives us still the flexibility and the freedom to build something uniquely Drupal on top of that, that remains a market leader the way Drupal is today. It frees us to do the parts that are actually cool. And so this is where we end up in terms of the new page request flow. Request comes in, we have this kernel that takes care of routing that request to a controller. Controller, think page callback only OO and fancier and more powerful. That controller returns a response object. And that response object can be an HTML string, it can be an HTML fragment, JSON response, a redirect. It unifies all of that stuff. So you don't need to call location headers in the middle of your code and then call exit and hope that things still work. And that controller can also make a complete sub request which goes through that exact same process. So every block is or can be a separate internal HTTP request or separate request from Varnish or separate request from the browser in Hinclude and it's tortoises all the way down. Does anyone actually get that reference? Okay, I never know who's gonna get that one. So this is where we are pushing towards and it's where we are not at yet. So one of the other big advantages when we're mapping up to a controller in Drupal 7, the way you map off to a page callback is by the path. All you can map on is the path. In Drupal 8, you can map on path. You can map on the MIME type. You can map on the HTTP verb. So we can actually do things with HTTP put if we want to. You can do things with HTTP delete. We can do post. If we actually found a use for it, we could even use HTTP patch. There is in fact a patch command in HTTP, a app that anyone uses it, but we could support it if we want to. So the kernel in particular, I wanna spend a little bit of time on this. It's in there. I've never used it, but it's in there. So kernel, this is the most important part of the flow. An HTTP kernel in symphony and now in Drupal 8 is simply an object that implements this interface. Request goes in, response goes out. That's it. That gives you a lot of flexibility to nest things inside each other without them realizing they're being nested. And that's where you get that ability to do sub requests sanely. That's where you get the ability to break up the page. That's where you get the ability to do HTTP based caching. Symphony comes with a default implementation of this interface that is quite nice. We are using it now. Basic flow of control, request comes in, and a request event fires. Events again, think hook. And then you can mutate that request. Then we have a resolver which says, okay, map that request to the controller that's going to actually do something with it. Controller is just the thing the kernel asks to take care of a request. That gets us back a controller and the parameters for it, which we call and we get back a response. You resolve the controller and the parameters to it. It's technically two operations. Then that gets us back a response, which we can return because that's already wrapped up and taken care of the esoteric weirdness of HTTP. Or if it returns something that's not a response, we get another event that fires that lets us mutate that. So right now, all page callbacks return strings or render arrays rather than response objects. So we have a view listener that takes that and mutates that into a response object. So we did not have to rewrite every page callback in all of Drupal yet. We should eventually, but we haven't needed to yet. If along the way you have an error, you throw an exception and that gets handled and that can give you a response. So you can do much better error handling than we can do now. You can also make a sub-request and run through that entire process again and then merge the requests together. And then anywhere you see request, that's cacheable at the HTTP level. And you can do that symphony ships with on HTTP cache implemented in PHP. Think varnish ported to PHP. And so we can use that as our page caching mechanism and block caching mechanism in a much saner way than we've got now. So this workflow is in core today. We are not fully leveraging it yet. And I say yet because I'm hoping that we can get rid of that yet in the next couple of weeks. So does this sound good? Good because it's not done yet. It's far from done yet. And now we get to the begging part of the session. So here's what we've managed to actually accomplish so far. We've got the request response workflow in place. There's still a few places that we're not leveraging it yet. There's open patches for it. Like Drupal go to is still there. We need to replace that. But for the most part, the request response logic is in place. We have that kernel based workflow. So we have that controller, request object, exception handler and so forth. That's in place at the moment. That's already running in Drupal 8. We have an event dispatcher in place. Event dispatcher does not replace hooks entirely. It replaces the low level bootstrap hooks. It replaces the stuff that's in, it's used for the stuff that's in the kernel flow itself. We're not replacing all hooks, not in Drupal 8. Just the stuff that's along that critical path there. We've got the kernel in place, that's redundant. And we have the symphony dependency injection container. Who here gets confused when I say dependency injection container? Okay. Short version. A dependency injection is use function parameters the way they're supposed to be used rather than calling from a function to a bunch of other things and having hard dependencies. That's really all it is. What's that? No. I'm still confusing, Peter. So if you have a function that calls a function, that calls a function, that calls a function, that calls a global. This function is now dependent on the save of this global. Go to task. Try unit testing that. This is why Drupal has very few unit tests compared to system level tests. If instead you have a function or an object into which in the constructor you pass a bunch of objects and they can just call those rather than instantiating it themselves, then you can pass in fake objects and unit test it. You can pull apart your code and work on it independently. You can have two people working on different parts of the system without breaking each other. So you can actually work on theming without breaking entity load. Which is kind of nice. A dependency injection container is a fancy academic name for an array of objects. Really all it is. That then takes care of, this object requires these five other things to be passed into it. It just takes care of that for you once you've set it up. It sounds a lot scarier than it actually is. And Jess is still wincing. I was actually smirking, but I don't think they're gonna do that. And so we've got a couple of things that are using the injection container now, but not most things. So that's where we are now. We have a lot of really cool shit in core now that we're not really taking advantage of. And if Drupal 8 shipped today, it would work. It would just be horribly over engineered and not accomplish anything really new. Few things here and there, but really nothing really new in earth shattering yet. If we want the really new and earth shattering stuff to be there, here's what we still have to get done and what we need your help to work on. So first of all, we need a new routing system. That is somewhere around two thirds implemented at the moment. This replaces hook menu with a symphony style routing system. I have some slides on that later if you really want. That lets us do things like routing based on MIME type, routing based on HTTP method and so forth. Right now core still doesn't do that. That patches in progress, needs reviewers, needs people to help figure out some of the edge cases there. Our Ajax system is still using anonymous arrays that you kind of hope you can figure out. This needs to be converted to you really using the symphony logic directly, return a response object that has the information on it we need. There is an open issue. I will be putting these slides online. All of these links are live. I have a description in this issue of how this should work. We just need someone who understands Ajax to jump in and make it happen. Content negotiation. Right now we can map based on MIME type but it's a hard coded list of known MIME types. That's really not flexible enough. We want something better than that. We have a start on a new MIME type negotiation library that is based on Apache's mod negotiation. Really powerful algorithm. This is not done. Wammelton has started on it. It's actually a project on GitHub because there's nothing Drupal-centric about it. We need someone who can help carry that forward and really nail that. So they begin to pull that into core and then be able to map on is this JSON-LD, is this our custom Ajax for ah-ha, is this some other type of JSON, is this atom? That kind of information, we only have a very rudimentary form of now we need a full on system for. Entity property API. We want to be able to do real content staging, real Drupal syndicating to Drupal content staging. In order to do that, entities need to get a lot cleaner and a lot more standardized. Work on this is in progress. Fago and Dixon are working, who was in their core conversation yesterday? Okay, all the stuff they're doing is important for Whiskey because that is how we can then take an arbitrary entity and say, okay, serialize it to JSON, ship it across HTTP somewhere, turn it back into a node object and call save. That's where we want to end up. We're not there yet. This needs to finish first. Symphony has a fairly nice session handling system that they modified and upgraded specifically for us to be able to use. It's really nice. We have a patch to switch our session handling to theirs, which helps clean up our bootstrap and hopefully lets us make the bootstrap thinner and help the installer and various other things. That's been sitting for a while now waiting for our reviews. So this is not directly web services, but it is, here's this ugly piece of code that we've got a replacement for, that the code for it is already sitting in core because we pulled in these libraries. HTTP, that's one of the holdups on that patch right now, is that question. But yeah, it's a session swap out. HTTP based caching. Remember I said we had Symphony comes with that varnish NPHP library. We're not using it yet. We need to. There's a patch in progress on that, but it could use reviewers, it could use people who understand HTTP to help with that. Is Mark Sonnenbaum in here? Okay, Mark Sonnenbaum is working on that, but he only has so much time. Block URLs. In order to do this, we need to figure out, okay, what is the unique URL address of a block? Part of this ties into the Scotch initiative, but we need to figure out how we're going to expose that to them so that they can build that layout. Once we have that unique URL for every block, then we get block level caching kind of for free. Things like autocomplete can easily, I have an extra letter in there, easily be ported, yes. Can easily be converted over to the new routing system. That's a fairly straightforward change. Once the new router's in, we just need people to sit down and do it. We don't actually have that many of them. There's the Ajax system and autocomplete, and I'm not sure that we have any others at the moment. Cron has already done. We need to figure out, for the Scotch initiative, for that layout stuff, how we're going to actually glue those two pieces together. And that's a tricky problem. I don't have an answer yet. We need to find one. And then of course, there's this question. We're just ripping routing out of hook menu. Menu links are still gonna exist. Hopefully they turn into entities, but that's a separate process. So what becomes of hook menu, and the stuff that's in hook menu now? I don't actually know. We need people who can dive in there and figure out what makes sense to do with menu links now that they are not joined at the hip with the routing system. So this is stuff I feel has to get done. There's other things that would be really nice if we get done, but could live and contribe if we don't make it in the next three months. Once we have those standard entities, we want to be able to serialize them to JSON-LD. If that lives and contribe, that's okay, but I'd much rather have that work ready to go when Drupal launches. And if we can get part of that in core, great. Lynn Clark is who I think just walked in back there is leading that work at the moment. Outgoing requests. So for everything we've talked about is incoming HTTP requests, serving requests. But a real web server, a real web services system needs to be able to make requests just as easily. We have a patch right now to replace the ugliness that is Drupal HTTP request, which misses a lot of important features with Guzzle, which is another third-party library that's used by a lot of symphony projects that has far more features than Drupal HTTP request that has like of the 11 features we listed off that we wanted it in a library. It has like 10 and a half of them. Only problem is it's about a megabyte in size. So we wouldn't be loading all of that on every page, certainly, but it's got a lot of code. So do we use that? Do we use a different one that's smaller and less capable? How do we handle that? We need to resolve that. Could happen in contribe, but I'd much rather have that in core if we don't need to think about different libraries for that sort of thing. Path alias refactoring. This is mostly a cleanup, but now that we have this more robust request system, we can do a lot to our path alias system to just simplify it, to make it more modular, make it easier to swap out if you're not using it or to swap in an alternate implementation. Cat Bailey is working on that patch now. It could use reviewers. Generators. Basically, that's using routes in symphony to generate URLs by name. So it's roughly equivalent to URL, the URL function, but instead of hand crafting a string of node slash dot five, you generate a route to the machine name node page and a parameter of node five, an associative array. This is great because then you're separating your link from the actual URL. So if you really wanted to move your nodes from node slash to content slash across your entire slight, you could. If we can do it in such a way that we can support fallbacks, you could have natively different node types at different base paths. I'd love to see that. If it doesn't happen, it's not the end of the world. It's just unfortunate, but I would still like to see that happen. Binary stream response. Symphony support stream responses. So instead of iterating over, instead of building up a gigantic file in memory or something and then trying to print that, it can create a response that when fired, rip stuff off disk and sends it. Or suck stuff out of some third party service and sends it. Very efficient. We're using it in a couple of places now, but even better if our code doesn't need to do an iterate over a file off disk every 1,024 bytes and it's gross. Because there are way faster ways of doing that. There is work that we've been pushing upstream in symphony to simplify that. That I would love to see get into symphony because then we can use it. Again, not the end of the world if it doesn't happen, but it'd be really nice to get done. That dependency injection container, we're only using a little bit right now. Anything we port into it becomes unit testable, becomes lazy loading and doesn't actually cost us anything if we're not using it in a given request. Anything we can move in here improves testing and improves performance. We just need to sit down and convert stuff over to it. There's a lot of those low level hooks, hook URL inbound alter, hook init, hook boot, that really could go away. Because we don't need them anymore because the symphony requests, or the symphony events that are already there accomplish the same goal. So that's a straightforward clean up, remove old crufts and port things over. Forms currently, who here actually understands how forms are processed on submit and Drupal? Okay, not everybody. You realize that? Honestly, no one. Okay. How many people realize that in order to submit a form, we halfway render a page and then process it and bail out halfway through the page with a redirect? Isn't it gross? So there are a couple of ways we can clean this up now. The easiest, and this is something someone can work on today, is when the request is coming in originally in the original request event, check and see if it's a form submission, load the form processed right there, and assuming there's no validation error return right then. We can skip over most of the page that way, much cleaner, much faster. The more we stuff we push into the injection container and the more stuff we pick apart, the more stuff we can do lazily, which means bootstrap gets thinner. Everything we move out of bootstrap to lazy load to use the injection container to not have to do on every page before we get to the actual kernel makes responses faster. And when we're issuing potentially multiple requests from Varnish, that really helps because every request cost gets born multiple times. So anything we can do to make bootstrap thinner is gonna help web services. And anything tagged whiskey or kernel followup, which this link goes to. I think there's somewhere around 30 of those right now. Need someone to work on them. I'd like to see most of those green before December 1st for code freeze. Who wants the help? I'm not seeing enough hands. So what we wanna do is, a lot of the stuff is legitimately complicated. I'm not gonna whitewash that. A lot of these are complicated, low level, get your hands dirty stuff. So what we need are people, I'd say two per issue at least, who are able to just dive in and commit time for several weeks to make sure that these things happen. So if you are interested in owning one of these issues, I will support you on it. We're having a meeting right after this session during lunch back over in the Coder Lounge in the Westin Building. Come talk to us. We're going to the other building. There's a more room there. Okay, well maybe we'll do it here. Well, we're meeting somewhere right after this to map out who's gonna tackle which piece. How are we going to make sure that these get tackled instead of falling off people's radar? How can we support people in owning these issues and really getting them solved? And again, we need multiple people for each one of these. There is nothing more disheartening as many of you know as putting time in on a patch and then it sits there in the queue waiting for a review for the next four months and by the time someone looks at it, it doesn't apply anymore. So two people at least per issue is what I'm targeting. Think we can do this? We've got three months left. Think we can do this? I hope so. Got a half hour of questions and discussion, microphones right here. Any volunteers, anyone want to say something? Just walk up to the microphone. What about the installer? What about what? Installer. The installer. So there is work going on to, who's actually looked at the code inside the Drupal installer right now? Did you run screaming? I did. So we have the potential with the symphony framework with the dependency injection container and so forth to convert the installer from a one-off hacky script into a micro application of its own. Built on all the same principles as Drupal Core that can install Drupal and do the same thing for the updates.php file and so forth. There's a patch for that right now. Latharian is working on that. Again, like all of these others, could use support, could use someone else to work on that. That's not critical for web services. That's critical for this piece of code is ugly and we have the potential to make it less ugly. So I'm not gonna be focusing about myself but if that's your passion, please don't let me stop you. Talk to Latharian, he's taking point there at the moment. Do we have any Drupal specific modifications to symphony or are we strictly using upstream symphony? We are submitting pull requests to symphony upstream that we can then pull back down. And we have already 10 or so pull requests that have gotten in just from Drupal people that have written stuff. Some of them are fairly minor. The largest one actually symphony natively doesn't actually do route matching on anything but minimal part of the request. We've started to introduce a new part of their routing system to do full request matching, which we're using. That still needs to work upstream in symphony as well. But yeah, the symphony that's in core is vanilla symphony but we have been working upstream in symphony and they've been very receptive to that so far. So any work you do in symphony itself is also benefiting Drupal. Cool. That sounds really cool. How does the anatomy of a module affected by a lot of this object-oriented cool stuff coming into what used to be a mostly procedural system? I expect Drupal 8 to be something of a hybrid. So some hooks are going to turn into listeners which means they're going to be classes which means they lazy load for you and so they're not going to weigh down your request if they're not used. Some hooks are just going to say as they are nothing we're doing is going to affect those like hook node load, I'm not touching that. Page callbacks. Some or all of those are going to turn into methods on objects which like anything else can lazy load. How much of that happens is going to depend a great deal on just how much manpower we can throw at it and what exactly Scotch ends up doing there. So a lot of that is still to be determined. But yes, modules in Drupal 8 I expect to be half OO, half procedural depending on what it is they're doing. So there will certainly be some modules that are just OO which suits me fine personally. Yeah, quick note on JSON-LD. I actually have a proposal available on the Whiskey Group. It's, I think it's a second post right now. There's an implementation of JSON-LD in Drupal 7 contrib, but using the same idea that we're planning to have in Drupal 8. It's not complete, but I'd like to have some feedback and see whether that's the wrong direction or if we should continue in the same direction. Okay, so if you're interested in JSON-LD, you know something about semantic web. Talk to him, talk to Lin Clark. There is a meeting also at six o'clock today in the corner. Talk to him at six o'clock. What do you expect in terms of performance when Drupal 8 comes out? My hope is that on the micro level, certain things will get a bit slower, but on the macro level, the architectural performance and performance we can make will overshadow that. So like processing an event is more expensive currently than firing a hook. There are things we can do to make that faster, but that cost, I expect, will be offset by a typical page request because we can have much more robust caching. We're gonna be rendering this part of the page instead of this part of the page, so it'll be much smaller so it'll be a net win overall. That's my current plan. That's my hope. I have not benchmarked at a micro level yet for that. We're focusing on architectural level performance improvements and micro level benchmarking that we'll do after code freeze because we can still make those changes later. That's kind of the approach at the moment. So in Drupal 7, we have this page callbacks and in Drupal 8, we still have them, but we also have this controller thing. And imagine that the controller thing should be an object, a class or something. And how do you imagine that we will map those old page callbacks to controller objects? Will we group some of them together or how would it work? So a controller in symphony can be any callable. It can be a function, it can be an anonymous function, it can be a method of an object. At the moment, we have it set up so that any function is assumed to be a legacy page callback, so we have to handle it differently. But my hope is that most controllers are methods on classes because that's, I think, the most performant. Depending on how much, again, how much manpower we can throw at it and what scotch ends up needing, that may or may not happen, so we may still have some function-based controllers for legacy reasons for now. Again, I don't know, it's gonna depend on implementation details as we plow through it and resourcing. So could I mention that maybe someday in the future, the node module would have one class with a lot of controller methods, or would you rather split this up in some way or how would you reflect on that? So how will modules look in the future, that's a basic question, or the part of the page call? I believe symphony and most rail-style frameworks, which symphony is not, but it's similar in this regard, have all of the CRUD operations for a given object type or on one class. I don't think that's actually the right approach for Drupal. My guess is we'll end up with do what makes sense in that case. There's nothing stopping you from having a module that provides eight controllers spread across three classes if that makes sense for your use case. So again, that level of implementation detail I don't know yet, I don't think we're going to know until we actually can start writing those and see, oh, so what does this actually look like in practice? It's not going to end up with every module has one huge class followed by its page callbacks, that's not happening. Should I make the next, or I had another question. Okay. Okay, so dependency injection container, as I understand the way that we want to use it is that we have some kind of configuration for an object and so on construction all the stuff the dependencies can go in and the object itself does not need to depend on the container. An object that is being managed through a dependency injection container does not know that it is inside an dependency injection container. That's a good thing. That's how you can just rip it out, stick into a unit test and test it manually. If you look at the current router patch actually, I've got a very good example of that. We've got a number of classes that use a database for dumping route information. They're all pure unit tests because all I need to do is pass in a database connection. So the point is that at this point it's not lazy anymore really because all the dependencies have to be constructed and put into constructor. And so some blog posts on the internet talk about some lazy group dependency resolution but then again you need to know the dependency container because then you have to pull it when you need it. So what is the solution? Do you have something in between that you don't need to the container? So you can still lazy. In some cases you do want to pass the dependency injection container into an object. In that case what you're doing is a service locator and then it can just call that object and get stuff from it as needed. In most cases when you have well-factored code an object is only going to have the dependencies that it's actually gonna use in the majority case. So as an example, yes if you're loading up the database backed cache system then it's going to have to load up the database. But it's gonna use it so it's fine. But if you never invoke the cache system then the cache system never initializes so it never initializes the database. Yeah but if you have something that wants the cache system just in case it needs it and then it doesn't use it and then you have the database already and everything. Then arguably that module needs to do something differently because that's a bad plan. Yeah it's not a perfect setup. It's not nothing ever happens at all unless it's absolutely needed. But it's certainly closer to that than where we are now where we load 100,000 lines of code and use 4,000 of them on every request. So it's certainly better than that. So on the service locator would be not just one big thing for everyone but it would be a facade or something for just an adapter for just one purpose maybe. And then another. Now there's one dependency injection container but just loading that container up initializes nothing in it. When you ask for something out of it it then loads just the things that object depends on. Yeah okay, that's. We can go over that in detail another time. Yeah one more question in the direction of how modules will look in the future. You mentioned that some hooks are going to go away in favor of listeners. Can you explain how exactly that will look code wise? Like how if I'm a module and I wanna have such a listener what do I do? Looks like this. So this is event dispatcher a la symphony. So you created the event dispatcher object. Core does this for you. You have some kind of callable method anonymous function whatever called add listener. So you actually have to register it if not a magic name the way hooks are in the setup of the injection container actually. So I'm gonna wave my hand on that for the moment to not get down into the weeds. But you can see some examples of this in core now if you want. And then you can have a subscriber class which is just a bunch of listeners as separate methods and then you register them this way and call add subscriber. Now when dispatch gets called on that event this is roughly equivalent to module and vocall then that's method gets called. Which means you can actually have methods that share information. So like hooks that could share information without having to rely on globals for example. So. Conceptually you could do it anywhere. What we actually have as of like two weeks ago. The dependency injection container in the setup of that you can register subscribers there. So you effectively have a setup hook for the injection container that is not called on every request but only when necessary and registering things in the container and registering events to fire all happens there. So it's more flexible but you have to manually register things. I think it's a net trade off. The net trade off is a win. So there was this at the very beginning of what later became whiskey. This was very much about butter and the central question was about having a context container to be able to say to hold information across several parts of the page like what's the current node? What's the current organic group? What's the current term, et cetera. And at some point it stopped being the central focus and rather yeah how we handle the HTTP requests and stuff like that. So does this context handling, I mean context as in context country module. Did it get like punted over to scotch or is it considered not an issue anymore because we can do that with the dependency injection controller or something? So most of the stuff that we were trying to build so a bit of history. Two and a half years ago, I started babbling about a thing called Butler which eventually got renamed to whiskey when it became an official initiative. Yes, that was a bad pun on my part, very deliberate. So that Butler whiskey effectively the same thing. The context part of that, we were working for a while on a context API for core. Most of what that would have covered is now either handled by the request object that we inherited from symphony or by the dependency injection container which we inherited from symphony or is handled by the way sub requests end up working and is scotch's problem. So that concept of centralizing that and not having all these crazy global functions is still there. It's just not one God object anymore. It's handled in logical separate places but the underlying concept is still sound. Sorry, then additional question. Does it mean that in the list of still to do or would be nice to have things, is there a task for converting current core code to move what would belong in there to actually get to a standard centralized location that country can then also use and set up standards for that or using that or? So it's not context in the sense of context API of a context module in Drupal 6, Drupal 7 which is a gigantic global array. The idea is the word global should be expunged from our vocabulary. So there is no massive central registry of the current state of the universe. Rather there is the request and that is all you care about and it's responsibility of the caller to that block to provide in the URL the contextual information you need. So yeah, there's no global registry of knowledge because there shouldn't be. Is that, I'm not sure if that's answering your question. Okay, so yeah, that original context API approach turned out to not actually be a good idea. The user and the current theme and everything will part of that be end up in the dependency injection container or will it be in the request object or where will we put that stuff? We probably need an issue to decide where some of these things go. Because if it's in the injection container then we are no longer, this container can only be used for this request and otherwise we need to rebuild it. And so where does it go? Well the injection container soon as another patch lands will get compiled. So it'll be fairly fast and fairly stable. I expect current user will probably end up on the request object, my guess. Current theme, I'm not actually sure. That's probably get added to the list. If that's something you're interested in, talk to me, let's put up an issue for that and we can start working on it. Yeah, some of this stuff that's currently global we're just not quite sure where it's gonna fit yet. We're gonna try and get as much stuff as we can into somewhere logical. We're not gonna get all of it. So during the request, the dependency that injection container gets a lot of objects inside and piles up that pile up. And so this is some kind of state but if you would have two requests could you reuse the same dependency injection container because it's not kind of dirty? Kat, you wanna take that one? That's what's combining. Microphone, microphone. Okay. So there's a patch in place to compile the container which means as long as something hasn't happened like a new module has been enabled you're gonna be reusing the same container and it's all gonna be compiled to disk. So. And like serialize it. Well, cause at the moment it's the way it works. It's being like built on every request. So yeah, no eventually it's just gonna be like it's just gonna be one big class that knows exactly where all the classes are. The objects that are managed by the injection container those at the end of our quest those expire and get garbage collected just like they do now. Things like the database connection. You open it when you start using it and it closes when PHP shuts down. That part doesn't change. Yeah, the idea was that if these objects contain some request specific information some module just puts the user ID, the current user ID into one of these objects that are instantiated for the dependency injection container. Okay, what you're talking about is request scoping. Symphony actually has a mechanism for that. So you can tag a given item in the injection container as depending on the request scope. So when a new request, a new sub request is fired Symphony will hold on to that object, create a new one that depends on the new request and then when you exit that request scope throw that one away and go back to the old one and it just takes care of that for us. That's another one of the nice things about its container. An earlier question. Also you mentioned in the Butler, the original Butler presentation in Chicago about including a unified plugin system as part of Butler. Can you comment on where that stands? Is that part of another initiative or? That got forked off to the Scotch initiative back in February. That landed, that's in Cornel. It still needs some cleanup and it still needs people to help implement it in the 15,000 places that it's useful. We're not gonna get to all of them but if you're interested in that system talk to Chris Van Der Water, he'll be here in the last session today. He needs hands just as much as I do. Anyone else? Who is interested in helping and knows that they are going to have the bandwidth to be able to do so in the next couple of months? See a couple of fans. Okay. Second question in the hard part. I admit, the second question in the hard part it's kind of hard for me to measure my own bandwidth at times. So I fully appreciate that but we need to make sure we can build a team that can just tackle these issues and drive this home because I really would hate to end up with a Drupal 8 that is two systems sitting next to each other both of which are half complete rather than one system that actually does everything we want it to do. As a Drupal 8 is chippable today, all the tests pass. That doesn't mean I like where it stands right now and we want to finish this process just to make sense we can. Hi, so just sort of a plug. So some of you that might be concerned about how much bandwidth you're gonna have over the next couple of months. Some of you maybe are full-time employed with some employer. That employer might be very, might have a business that depends on things like content staging being possible, native apps on mobile devices being possible. So go back and talk to your employer and see if you can maybe get some time to work on this. Yeah, if you want request handling, if you want web services to work in Drupal 8 rather than be a hack layer you can sell that to your boss. If you want the core system to be able to support one good layout system instead of a crappy layout system in core and a couple in contrib that don't talk to each other then we need to get this work done. You can sell that to your boss as well. If you need help with the sales pitch, talk to Alex, talk to me, talk to Jess. What? No, don't talk to Jess. Okay, don't talk to Jess. But there are people who can help with the sales pitch too if you need to make it if you're interested. You, which is going about to change I guess. Currently we have in this one hook we give information about the route and also about meter information to put this in a menu somewhere to make a breadcrumb and to make tubs. And this is dirty but it's kind of convenient and it guarantees that for all these admin pages you don't forget to put the breadcrumb or the tubs but you just get it all for free and you just use one place where you put all this stuff and if you change it you're only changing this one place and if we split this up then will it make it more difficult to keep this all synchronized? Isn't it for some use cases nice to still have this hook menu with both things together? That's item 10 on the list. What do we do with menu links now? I don't know. Yeah, it's beyond many links, so microphone. The admin pages actually do some really nasty direct queries to build admin pages. So I think we should split this up. A lot of the structure of hook menu was essentially mimicking what Drupal 5 did in order not to... Which means Drupal 4.5 because it didn't change. Well right, or not 4.5 but maybe 4.6 anyway, whatever. But in order not to make people's heads explode as they converted from 5 to 6 a lot of these behaviors were retained even though they were very hacky. I think having the names callbacks will help because then you can say my admin pages have these names and you can go then and change everything else about them all you have to do is specify the names the same with links. I mean Drupal 7 already uses menu links a lot less for actual user navigation. Like you generally don't see that large pile of links in the left block that you used to see. So again, I think what we have now is a convenience system where we know that a path exists and we automatically register it as a link. I think making that explicit is a little bit more work but I think it would be a lot cleaner. And yeah, I think that overloading that one hook with all that stuff is just led to more problems. Yeah, I would agree. How you see this initiative would clean up the overly implementation, the iframes and stuff or is it a question for a lay out group? Overlay. Yeah, overlay. My hope is that one of the things we can do with a stronger web services underpinning is overlay becomes just another type of rest request. That means we can clean up that process and have an actual client side app in JavaScript that is overlay that makes real requests against the server rather than the kind of tricky backdoor-type things it does now that are kind of gross. We need to get the new router in place first before we can do that. We need to get the revised AJAX system in place to take full advantage of it and then we can start cleaning up overlay. I'm not really focused on that one. I'd love it if someone did after we get to the point where we can do so. So I'm hoping we can get to there but it's not something I'm looking at directly. Okay, we're just about at time. If you want to join us for a strategy meeting, I guess let's just meet up at the front of the room here and then we can figure out where we're gonna go. Otherwise, enjoy lunch and hopefully still see you in the issue hues because as I said, there is a legitimate risk that we end up with a half-written system that no one's gonna like. I don't want to end up there. I need help to get to that point. These slides will be up on the internet later today. I will tweet it. Just follow me at crel and includes lots of links to places to go help. I don't know if you have anything to add to this key or parallel dash program. And any of those types of things that you don't want to jump on, I got to mention we also have we've been asking people to dash with C in the other week. New New York time, so that's what I'm trying to do. And I think that's trying to get to the entire work day. Thank you.