 Who remembers what it stands for? About half of you. All right. So the WISC Initiative is Web Services and Context Core Initiative, which, in its original conception, add a number of moving parts to help rebuild Drupal as a more modern web services-based framework and do a lot of cool stuff with that. First of all, we wanted to have a centralized plugin system. So currently, in Drupal, every system that has a swappable component does it differently. Menu callbacks, field formatters, text formats, image styles, they all do something completely different. And we want to unify that into a single, solid, object-oriented model. Those of you who've seen tools plugins before know how nice it is to have a single plugin concept you can work with. Same idea. We actually drew a lot of inspiration from the way C-Tools works. And these can be provided by modules or by themes. Second part that we wanted to do was context-sensitive output. What does that mean? There's a lot of information in HTTP on the web that Drupal completely ignores right now. And we throw stuff into Globals, which is how PHP naturally works, which is a very bad thing. And we want to take that and encapsulate it into a single channel and get rid of global user, get rid of global language, handle that in a much better way that lets us carve out parts of the request response system so that we can swap them around more easily. We can eliminate globals. We can unit test them. Again, architectural-level refactoring. And then with that refactoring in place, we can now build Drupal as a real rest system. Right now, when a request comes into Drupal, we decide what page callback is going to handle it based on the path. And that's it. And that is a 10th of what HTTP actually offers. There's so much more there. There's different methods, get and post. There's different MIME types. So you should be able to respond differently to a request for text HTML, or application JSON, or SVG, or whatever other format. Path, domain, there's a lot of information in there, the scheme, HTTP versus HTTPS. The result information, we completely ignore right now. And if we want Drupal to be a forward-looking, next generation platform for doing web services, for serving up data to mobile applications, then we need to be able to look at the entire world that we're given, not just the smallest sliver of it. And then once we've got that richer capability in place with all of these tools, then we build a new unified layout system. Drupal right now has three layout systems. There's the core block system, which everyone hates. There's panels, which everyone hates the UI for. And there's the context module, which is really just the block module on steroids, and so it's not much better. And a lot of people hate that, too. So instead, with all this new power, I think I've just offended everyone who's used any of those. So with that more robust framework underneath, rebuild our rendering model along the lines of what panels does. But don't have to hack around all the things the core does wrong so that 2 thirds of that code and 2 thirds of that complexity just goes away. And then take the time to really think through a good UI on top of it. And this model of rendering then lets us have pull-based layouts. So who's worked with panels, a fair bit in here? OK. That's a good thing. That's freaking awesome. Yes. So with panels, you don't have inter-page body and then you wrap random stuff around it. Instead, you have a request and you have a layout and you have content panes inside it. And if you use many panels, those content panes can be layouts inside those. That model is more powerful. That model is a better model for building a page than what Core does now. And by baking that in at a lower level, you'll be able to extend that, clean it up, and then leverage things like ESI, EdgeSide Includes. Who's familiar with those? OK. For those not familiar with it, EdgeSide Includes are essentially doing regular expression replacement of your page in varnish. So you cache most of an HTML page in varnish. And then when a request comes in, varnish says, oh, there's one little piece of the page I know is dynamic. So I'm going to send a request back to Drupal or whatever for just that one little sliver. Get that back, put it into the page, and then print that. And that's much, much faster than rebuilding the entire page for every authenticated user. And right now, it's possible in Drupal, but not easy. There are a lot of edge cases where things break. But by using a strict pull-based model, we're able to build that kind of functionality in at a much lower level. That means that blog caching and page caching become the same thing. That means authenticated users are no longer inherently 100 times slower than anonymous users and all that kind of stuff. So that's what we were trying to do. That's what the WISC initiative set out to try and accomplish. And yeah, that's a lot. We knew it was a lot, but it's a big task. So from about March of last year, shortly after DrupalCon Chicago and the initiative started, through November or so, we looked at this problem, tried to think through a lot of the hard parts, had some false starts. And one of the things we looked at was, you know what, we are not the only project in the world that's tried to solve this. So let's see if there's anyone else out there that we can borrow ideas from or a little bit of code from. And the first thing we looked at was the HTTP handling. The superglobals in PHP are a bad idea, period. What's better? Well, there are a couple of other projects that have built better abstractions for that information. And okay, can we use one of those? So a couple of people from the WISC initiative looked at Symphony 2 and Zen Framework last July or so. And both of which had HTTP components. And we said, all right, between the two of these, Symphony's looks better for various reasons. So let's just start using that. And shortly after DrupalCon London, we put the Symphony HTTP library into core. I said, all right, this is our abstraction there. We don't need to worry about re-implementing that part. Now let's move on. We moved on and tried to build the rest of the system that we're talking about here. And kept running into a wall of, I can't wrap my head around this. I haven't been talking to you for the past year and a half. I have no idea what you're talking about. I just does not make sense. And that's a problem, both from a just practical standpoint and also from technical standpoint. Because it's kind of hard to review a patch if you don't understand its context. No pun intended. Yeah, no pun intended. Then around late November, early December of last year, we'd hit a wall with what we were trying to build called the Context API that was going nowhere. And so I started talking to some of the Symphony developers and realized everything we're trying to build architecturally, they've already done. And they've done it in a way that makes it possible for us to borrow just the pieces we want and not pull in the entirety of Symphony. So why are we wasting our time? So it did a proof of concept and threw that out. A lot more discussion. So Dries called a bunch of people together in Boston. A little over a month ago now I think, at Acquia. And just try to think that, sit down and think through just how far are we gonna go with this thing? Just how much, do we want to leverage Symphony? How much of this architectural change can we actually swallow? And our conclusion was, if Symphony does it, when we can use Symphony, let's use it. It's open source, go for it. And the fact that Fabien Pontoncier, the project lead for Symphony, was willing to fly in to help us sort through some of these issues and come here for the conference, helped a lot. Symphony's community from everything I've seen. Yeah, Fabien, Fabien, are you in here? Yes, I'm in here. Okay. Right here. I'm in here, I'm in here. Yeah, they, yes. Yeah, my interactions with the Symphony community to date have all been very positive. You know that feeling when you walk into Drupal and you get that kind of group hug, let me help you feeling? That's what I've gotten from the Symphony people too. Except no hugs. Yeah, they're not as huggy as we are, but they're just as friendly. So, you know, great, wonderful, and there's still an awful lot here. There's still an awful lot we're trying to deal with. Make Drupal rest-centric and web services and a new layout system and this and that, just logistically and structurally, a lot to swallow. So what we decided to do was say, all right, fork it. And we now have two core initiatives, web services, which we're still calling Whiskey because it's a great pun, because I don't actually drink, and new blocks and layout everywhere initiative. So the new, you know, Whiskey 2.0, Whiskey TNG initiative. Yeah. Yeah. Is Symphony has a really solid HTTP handling and routing system. We're gonna use that. So HTTP Foundation Library out of Symphony, the HTTP kernel on their routing system. We're just gonna adopt that. And what currently is the menu system and delivery callbacks morphs into that system, into that model. And we're gonna try and follow that architecture as closely as we can. Patch for that is in progress in the issue queue. Currently I'm fighting with Testbot about it, but that should hopefully be landing in the not too distant future. And what this lets us do is approach the web from a Rust-first perspective. That is, HTML pages are nothing special. Currently in Drupal 7, everything in the architecture assumes we're returning an entire HTML page, except for the couple of edge cases or we're not and whatever. Turn that around. Everything we're returning is an HTTP response to an incoming request. Occasionally that will be a complete HTML page. But it could also be JSON, SVG, all these other fun things. We want to be able to handle get requests and post requests and put requests separately from each other. We want to be able to build a mobile app or a desktop app that can talk to Drupal without ever going through the admin interface and still do everything. We want to be able to do that, whereas right now it's really hard to do. And then to really, who was at the last core conversation earlier? All right, so Dixon, Dick Olson was talking about doing deployment. We need some kind of standard serialization formats. I agree entirely. He and I have talked about that. We want to be able to say, for any given entity, here's how it's exposed through web services and you can save it and read it and write back and forth and have Drupal Sikes talk to each other over HTTP without human interaction. We want to be able to do that in a standard form. And what that lets us do is deployment, is content sharing, is offering data to mobile devices, is all kinds of other fun things that are going to be not edge cases like they've been for the past five, seven years, but the norm, which is what they're going to be in about four to seven years. We want to get there before the rest of the market does and it's gonna be a race, but I think we can pull it off. Okay, so what about this fancy layout panels and core stuff? What's happening with that? That is technically no longer my responsibility. So I'm gonna hand it off now to our newest initiative lead, Chris Vanderwater, ClipsGC. So I'll continue on because we've got a few more slides here, but real quick just kind of introduce myself a little bit if you aren't familiar with who I am. I'm a SeaTools co-maintainer. Panels and page manager in that whole world matters to me really, really a lot. So to be here doing this for core now is very important to me because we need to do this right so that we can continue doing the sort of things that we're used to doing in panels, but hopefully just really nail it down in a user-friendly way. So kind of carrying that idea forward. We have the blocks and layouts everywhere initiative, which is what I'm running at this point. And we're gonna kind of open this up for questions here real shortly. So I'm sure there will be a lot of questions concerning these things, but just to give you kind of an idea, why did we do this new initiative? Larry explained a lot of it, but in short blocks just aren't up to the task. Many of the existing solutions replace or significantly change blocks behavior. Panels outright replaces it. And so it's pretty obvious at this point that core could really benefit from a stronger block solution. We're doing so many things from a contextual standpoint that it becomes a real question as to where does page content end and block content begin? And we're just going to kind of make a really hard dividing line here that there's no such thing as page content. It's just blocks. So in short, what does that solution look like? Wow, did I end up with? So Prezi totally ate this in the middle of the night, so sorry. So I'm just gonna skip to the next steps because I think I did that slide anyway. We have a plugin system that we've already built and it's existing inside of the repository that I'm working on for the whole blocks and layouts initiative. And that's actually gonna be really powerful for us in the long term. It's probably one of the first patches that's gonna land. It's gonna land largely by itself. And the second it's there, we could open up core to do a whole bunch of other things that are totally outside of either one of our initiative but people could really leverage it to start making all sorts of things within the system pluggable. We're gonna redefine the block system and I've already got a pretty good definition on that going, so if you wanna see it and I'm really hoping that people do want to see it, I would love to start showing that off and getting people on board with where it's going, why it's going that direction and start kind of poking holes in the edge cases of where it might fall apart. We're gonna have to build a responder to the get method on text HTML requests, right? So this just happens to be a get on text HTML. Yeah, well, we basically need to build panels in right there and what that ends up looking in core is really up for debate still at this point. But I've got some pretty good ideas about what I want to see there and I think we just need to spend a bit more time on the analysis side and the design side to really nail down what that's gonna be and on that note, there's a bot directly after this session 215 in room 206 to discuss user experience for that. So if you're a JavaScript person or a UX person or you're just interested and want to see what gets said. We need you. Yes, please come. 206, I think it's on the bot list though. Once we have the layout system built, we're gonna have to start transitioning the existing themes to it and we have to start playing really nice with like the mobile initiative and things like that at this point and figuring out how to build mobile layout plugins which I'm actually really, really stoked about. I think we're gonna find some really awesome synergies sitting right there that Drupal has just not been able to leverage up until this point. And then the last thing I put up here is contextual plugins. The order in which things are happening within the whiskey sprint right now has led me to believe that I'm gonna have to hold off on that for a while. I changed my mind about that sometime in the last couple hours so the slide hasn't changed and we can kind of discuss that if we like. But Fabien suggested a specific use case there that's gonna require a few more symphony components and I'm gonna really encourage us to just embrace it and run with it. Rob, Loach, are you in here? Yeah, there he is. And I'm just gonna elect Rob to help us make that happen. So. He volunteered himself yesterday at a sprint so you're kind of stuck with it now, Rob. Congratulations. Congrats. So. Those are our slides and I think we're not even quite at the halfway point so we really wanna open this up for discussion but I wanna be clear about a couple of things before we do that. Like, technical questions, totally go for it. We don't want to divulge, we don't wanna get mired in a bike shed about what the architecture and things like that look like. We're happy to bike shed about that but we don't want to do that in this forum. And so, you know, if you have some specific questions that could be kind of bike shetty, find us, we'll talk. But we wanna open this up because the general perception is that there's a lot of fear and given the turnout in this room, it's either fear or excitement or a bit of both. So. How many are up there? Yeah. That's a good question. How many people here are more scared than excited? How many people are more excited than scared? Wow. I like that response. All right, so there's a mic. If you have questions, we are here to answer them at this point. No. No. Eaton is not allowed to be ambivalent. Really? I'm okay with Eaton being ambivalent. You mentioned the menu system and how Symphony will impact that. Can you clarify the difference between the menu system as in hook menu and the menu system as in the navigation for a site that might be defined through primary menu, secondary, et cetera? Yeah. So menu system as of Drupal 7 does about five things and that's part of the problem. The part of the menu system that we are dealing with is routing that is request comes in, what piece of code is responsible for dealing with it? And our current plan as of about 24 hours ago is hook menu gets replaced with a new hook where instead of defining routes as path indexed arrays, you're returning an array of symphony route objects which are essentially the same concept as each of those items in hook menu but offer a lot more flexibility to handle method and accept header and so forth. And then a new system that's similar to the current menu router table behind the scenes for lookups and so forth but again with the symphony wrappers around it. Menu links, we're not dealing with. Tabs that are also tied into the menu system, local actions tied into the menu system. I don't really know what's gonna happen with those. At the very least, we're pulling routing away from it. If someone else would like to take point on detangling the rest of that, talk to Peter Rowlanden, who's the menu system maintainer, he's sitting right over here. And he's hiding. Yeah, really quickly on that and correct me if I'm wrong on this because I walked in on the tail end of the sprint yesterday because I had some training duties but we're assigning machine names to those things so we should actually be able to make those portable throughout the system even though they aren't necessarily configured. That's a good point. One of the big differences between the way Drupal traditionally is handled paths and the way symphony handles paths is we key our route information based on path. This doesn't work if we want to be able to have a get request and a post request and a JSON request go to different things on the same path and we want that. So instead, every route will be identified by a machine name. If you're worried about coming up with machine names, it's no harder than coming up with the menu callback function name now. Probably first cut, they'll all be the same. And then that's what we'll actually look up on when routing. It also means that when generating a link yourself, you will not be generating a link to node slash dot dollar sign knit. You will generate a link to the route item node underscore page with argument node ID. If that happens to have been moved by someone to a different path, everything keeps working which means you can reorganize your UI. You can reorganize your admin if you want to. You can put node ad pages in a half dozen different places and everything still works. So this is the whole point of moving everything to the block system because if the node ad component is an actual block and it's irrelevant what page it shows up on and you can inject into it the information it needs to know like, hey, where do you want to redirect to after someone finishes with this? Then it becomes really a plastic environment that we can completely rearrange the administrative system at that point. You can even put node ad pages on the display of some other node page and start doing crazy things like pre-filling node references to the node that you're creating it from or something like that. Not that Chris has ever done that before. Not that I've ever done this before. But you know, the mic's on, it's just really low. I can almost talk that loud. You want to come over and use the mic here? Yeah. We'll just stand together. Yeah, we'll just sit down. Okay, so yeah, but that's the whole idea of moving everything to blocks is we'll have a consistent layer that anybody can write output for anything for. And so there's gonna be a little bit of learning there but that frankly is probably the biggest change of anything that's being proposed from what a module maintainer's going to have to learn. And my objective thus far has been to make that new, because it's a class, it's an object. To make that new object system really dead simple and hopefully you'll learn it once and go wow, that's really easy. And instead of there being three or four different ways of handling similar things like Drupal does now, there's one and it works and it does all of them, thank you. Next question. Forgive me if I'm mixing up initiatives a little bit here but back when some of this context idea was called Butler, I remember one of the hopes was that we could cut down on bootstrap time by loading things a little bit more lazily. Is that still kind of part of the goal? Sort of. We would like to see that happen but it doesn't fall directly into either of our initiatives. So all the components to help make it happen are being committed to core and there's kind of an unofficial initiative to make the bootstrap lighter at this point. So we would love to see people get involved and do that but we really like, it's outside the scope of what we can do at this point. The way to make bootstrap lighter and less error prone is rather than initializing everything linearly, make each of these subsystems an object and initialize them out of a dependency injection container like the one we're gonna be borrowing from Symphony and then when you start using something it will initialize what it needs to and initialize the five other things it needs to work and that'll just kind of happen. Once we can do that, the process of bootstrap gets thinner. We're not directly working on that as part of our initiatives. If you would like to do that, please. Don't let us stop you. Please do so. The stuff that Rob Losch is gonna be doing will tie into that. I don't believe you're planning to do that directly. So Rob, we're just putting everything on you. So like the things that we're volunteering Rob for are the wrapper around being able to do that but none of us intend on actually going through and doing that, we're gonna use it for something else but it could easily do double duty. And if you would like to work on that, let us know, we're happy to help bootstrap you on that. Yeah, we'll throw all the people who are interested in doing that together. Yeah. Next. I have a question regarding the caching of a page that consists of several components or blocks or whatever you call it, several parts. So varnish can cache three parts of that and the other three parts are dynamic. So does that mean that varnish has to make as three requests to Drupal and Drupal has to bootstrap three times to deliver that three other dynamic blocks? Do we get some overhead from that? Yes, however, because Drupal is doing less on each of those requests, it's not the full weight of an entire Drupal page process. Also, those individual blocks can be cached independently. So if the page is mostly static and this block varies based on the user and only the user, then first time a user comes to the site, page is already cached, render that block, cache that separately. Second request, you get that other page, oh, and it's the same block put in, varnish doesn't have to hit Drupal a second time. And if you don't have varnish, symphony includes a PHP implementation of what varnish does and at this point my take on it is, let's use that, our page cache just becomes the same thing. So varnish style block caching becomes our primary caching mechanism for anything. Not trying to put your fearsities? Yes, right, but that's why we wanted to do all the bootstrapping things, but we don't have time to do that, which is why we're standing here saying, you all should really get together and do this whole bootstrapping optimization. Yeah, because we're not going to and your fears are legitimate, we're going to have some really great caching things that we'll end up doing to try and mitigate some of those issues, but what you're supposing could certainly happen. Okay. Hi, I have a question for each half. First of all for the HTTP sensitive routing question. Can an HTTP request be identified as one requiring being rerouted to a non-blocking IO backend endpoint or web socket or long pulling endpoint? In the use case would be a chat server in a pane or something like that. In other words, if we're going to privilege backend, can we also detect by the same method HTTP request that require asynchronous or non-blocking IO? So web sockets is part of what you're talking about and web sockets at the moment require a lot more work than core can handle on its own. There has been some discussion of how we want to support those. Really, to support web sockets, you have to have a long running process on the server. You can't have a, like PHP naturally does where it starts a request, does something and shuts down. There is a alpha version of a PHP demonized web socket responder that I actually ran into the developer of that at a conference in London, Ontario last year at random. So we may look into how can we leverage that. I'm not sure. The other option there is server sent events. I don't know enough about them to say what we can do there. I would definitely like to support them if we can. I just don't know yet what all the pieces are there. At minimum, I'd like to be able to do the stuff to core necessary to make it possible to do that in contrib. A lot of that being less globals. So a lot of things become a lot easier when we have fewer globals and more loose coupling because then you can have the entity system loadup inside a separate PHP app and do its thing. And again, that specific thing is not something we're working on, but that kind of architectural refactoring is a good thing to happen for that reason. Okay, thanks. And will in the panes, in the layout part, will there be tools in the panel panes so that the developer can easily set up client page elements that could call such? Let's suppose I had a chat server, a Node.js chat server using Sokiraio. So will there be tools so that I can easily program a client to one of those in a pane so I could easily set up a live chat in a pane or something like that? Okay, so the block system as we're defining it, like in this sort of an instance, if I'm understanding where you're going with that, you would end up building a custom block whose sole purpose is to do that. The second you do that, it's available to you in a pane to place wherever you want. I didn't quite hear the lesson. Once you're done building that block, you can, it falls straight into the tool set to just be placed wherever you want. Okay, thank you very much. Not a problem. My question is how, since we're going to start using the HTTP kernel component, how much of it are we gonna be using? Because as I understand it, that component also defines kind of the shell for Symphony's bundle system. So is any of that gonna be used as well? And if so, where does that end and where does the module system begin? So bundles are actually not part of HTTP kernel. Bundles are something, and Fabian can correct me if I'm speaking here, bundles are something that are handled and defined by the Symphony. What's that? Okay, so the Symphony bundles, we're not looking to use at the moment. Modules may change somewhat. We are pulling in the event handling system from Symphony that is similar to hooks in terms of the purpose it serves. We are not at the moment looking to replace all hooks with event handlers. Ask me again in Drupal 10. Yeah, that's like next week, right? Right. Yeah, so at the moment, it does not look like, Symphony bundles, you'll just be able to pull those and drop those into Drupal. If someone else can figure out how to make that work, more power to you, but I'm not really focused on that at this point. Okay. And ladies and gentlemen, Jeff Eaton. Yeah, I'm ready. I'm ready. I'm ready. I'm ready. I'm ready. I'm ready. Excuse me. So this isn't necessarily directly related to the stuff you're working on, but it seems like there's enough deep rearchitecture going on in what you're working on that it probably, I think at least relates. At what point do you think it may be necessary to start reexamining how we do our version to version site upgrade path? I mean, because the kind of stuff that you're describing, we have to start thinking not just about data migration but whether or not it's even possible to preserve layouts using any kind of automated migration process. Yeah, so I've been thinking about that a lot, right? Because I mean, how do you take Drupal 7, like just vanilla Drupal 7 and toss it into a layout plugin that hopefully, you know, I mean, if we're talking like Bartik to Bartik, I think I can probably make a pretty educated guess because Drupal 7's so limited in that regard, like you're not gonna be using the same block more than once. And if you are, if you're using context module, well, I don't actually support that upgrade path because I'm core. So, you know, there are some things like that where the answers aren't easy just yet, but I think that given just exactly how limited blocks in Drupal 7 and below are, we may get kind of a pass on particularly placing them in layout plugins. But there's this whole additional notion of like we have all this data that resides in the database and for example, I don't have a database table underlying block positioning or any of that, it's all CMI config management and that becomes a really legitimate question now. Now I have to figure out how to take tables that exist in Drupal 7 for a table that I have no need for anymore and migrate that data into CMI in such a way that it continues to work with those layouts that I said might be easy and like, there are a lot of hard questions there. Well, it sounds like that one's Greg Dunlap's problem for just migrating tables to CMI files. Because he said it was your problem. So, Greg, I don't think is in here. So yeah, it's Greg's problem. Also, for those migrating from panels in Drupal 7 or context module in Drupal 7, that's a great place for a contrib module to do awesome things and make someone very, very popular and famous. Just like happened with converting CCK to core fields in 7. If that is something that you're interested in, you will have a lot of people very happy if you work on that. But we don't have the bandwidth to do so, yeah. Next. So I was wondering if you could talk a bit about the kind of the multi-rendering to JSON or to Drupal render now. Is Symphony providing that system already or is that something that you guys already kind of thought through completely or is it still open? A little of each. So Symphony provides, or the Symphony components that we're leveraging provide the framework by which that logic is done and a couple of default implementations that implement it. We're going to be using that framework for how it gets done and some of the provided implementations. Without going into too much technical detail, for instance, the out-of-the-box default implementation for matching a path pattern to a controller, which is the thing that page callbacks essentially. The default implementation of that uses regular expressions and doesn't scale to the easily 5,600 routes that a Drupal site's going to have. That's okay. We're going to use the same interface and build something behind it that will probably look an awful lot like the menu router table does now but with a couple of extra columns in it. We haven't implemented that yet, but at a hand-wavy level, that's kind of what we're doing there. So the Symphony workflow with some of the Symphony code and some of our own code backing it. But as far as JSON versus HTTP, is each handler going to be responsible for returning a JSON object or is it going to be like standard, you just pass a standard object and it renders it as JSON or renders it as HTML? So that'll be two different controllers. So if a request comes in for get node one type text HTML, that routes to this controller over here and that does all the layout page stuff. If it comes in as get node one type JSON, it routes to this controller over here which is a different object and it loads that node object, actually takes the node object it's given, renders it into JSON in whatever standard format we decide to use there and returns that. If you want to render a node as SVG, you hook up another controller at get node one type SVG and you do whatever logic you're going to do there. Okay, thanks. So panels. I'm one of those people that tried it in Drupal 5 instead of it was way too much trouble was worth in Drupal 6, there were other options. So those of us who have workflows that use context and display suite and theme tricks instead, what should we be doing now to prepare for the future? Should we all switch to panels for seven immediately? I hear it's better and faster, but. Yeah, you should go learn panels. Earl Miles is giving a session tomorrow on panels. It is opposite my session on architectural trade-offs. I'm okay if you go see Earl instead of me. But if you're not going to see Earl, I expect you in my session. So the other key part to that is, one of the needs we try to meet is for the clients who want to have content editors have some basic layout choices, right? And the panel's UI is just entirely unsuitable for that. Display suite can be tamed to make that possible. Is the new system gonna provide options for non-technical page layout choices? There's a buff right after this one talking about that question. Yeah, very questioned, yeah. But, what's that? Oh, there's Earl. Yeah, so go to Earl's session tomorrow. He'll talk about that for what you can do with panels today. Yeah, so. Thanks, Earl. And as a really, as an additional answer to that, yes, the objective within Core would be to give something that is user-friendly enough that we can give content editors or whoever the ability to actually do that sort of stuff. Like, I don't want you shutting clients out of this. I want to build a system strong enough to give to clients. And I'm assuming Earl's gonna show this tomorrow, but the new panel's in-place editor work that went in in the last week is absolutely amazing. And I mean, Matt Cheney gave me a demo of it yesterday. And if you have not seen this, you need to go see this. Like, hunt these people down and find them. In a good way. Yeah, in a good way. I'm curious about the relationship between your two initiatives, now that they've split. Specifically, I'm thinking kind of about restfulness and with the kind of standard web framework rest system, you throw .json on there, you throw .html on there, you get different representations of the same resource, basically. And it seems like here, a little bit, maybe over-generizing that we have, the services initiative is everything but HTML and the kind of panels and blocks everywhere is the HTML representation-specific questions. And so I'm wondering, will that restful principle kind of carry on on the HTML side? Are we still dealing with entities as the restful resource where we can, with the same URL as the .json objects or do we have kind of HTML over here and .json different? Block pan. Yeah, so yeah. There is some gray area between the initiatives. That's why we are in constant contact. Part of the idea there is in order to support every block can do ESI, that also means every block gets its own path. So when you hit node slash five. And it's not just every block, it's every instance of every block gets its own path. So when you hit node slash five, there are internal sub requests that get fired to something like system slash block slash node block five. And to system slash block slash user block two. And so forth. And whether that sub request happens within a single PHP process in varnish or completely from the browser using backbone.js or something like that, is should be irrelevant to a person building a page. So a person writing a new block. So that's, the rest concept permeates the entire layout system. We just need a UI on top of it that makes that understandable to people who do not know what ESI is. And we're working on it. And also to clarify a few points on that. And we're still arguing about this. So Larry may disagree to a certain extent. But when I think of the web services side of things, I don't want to make the assumption that when you ask for node one as application JSON, you wanna serialize node back. Like that's an assumption that I think is not good to make. And so I think there needs to be some level of user interface there that can actually dictate what you get back when you ask for node one as application JSON. You may want something completely different there. You, you know, depending upon the app that you're writing or whatever, you could have very different, you know, foundational needs or, you know, you may end up writing a completely separate page to do those sorts of things, but. Or just a custom MIME type. You can have vendor specific MIME types that do, you know, node slash one MIME type, you know, vendor dot whatever it is you're doing and returns whatever it is you want. Details like that will get to when we start writing that part of it, I don't know. Yeah, but at that point, and I'm not saying this is a bad thing, but we're sort of like making up our own little niches in the web. Which might actually be sort of interesting in the long term. So I hope you'll figure out a follow up question. I won't get into the bike shed area. I'm actually the maintainer of the backbone module and that's kind of where my interest in all of this is coming from. But, you know, so when people look at a node page via HTML, are they actually calling the node resource? Or are they calling a page layout resource then? No, no, what they're, yeah. It'll be a page layout resource and that will dictate what actually gets pushed to the page. So you don't necessarily have to display a node on a node page if you don't want to. That's great, thanks. Yeah. And how much of the defaults are baked in and how much, you know, how easy it is to change those defaults is an open question. But we do want it, one of our goals is to make it possible to change every single path in Drupal without hacking core. Yeah, I would very much, I would feel like I had failed if the administrative pages weren't, you know, at it, let's add some new craft to this, you know. Glenn. So quick follow up question on block rendering. Would you foresee block rendering supporting different content types? So if you want to make a JSONP request for a block versus an ESI request. Or is that bike shedding? I think that, like if I can just answer that, I have no intention of seeing that happen. I think that that's probably a separate plug-in system and is where I see it slotting into the other side of the UI that we're still arguing over. Gotcha. And so on the routing side, I think one of the important tenants of restful routing seems to be like relating things with hyperlinks or hypermedia. Will there be, do you foresee a structured way of say relating the node one resource has a display at this resource or the node one resource can be edited at this URL? Is that, do you see a structured way? I think you can see that in the services module as it is now. It's not complete, but you know, you have create, read, update, delete, then you have targeted actions and relations. Do you see our routing system supporting that kind of metadata and linking? Whether that's in the routing system or not, I'm not entirely sure. That's probably the rendering layer that said, yes. Yeah, let's clarify the question. Are you asking whether the routing system knows what's on that page or are you asking whether, like, I could just put a note at it anywhere? I think I can actually clarify. So for those not more familiar with it, in rest theory for web services, there's the idea that at a given URI, URL is a resource. And when you request it, one of the things you get back, as along with the Data Athletic Resource, is references to other resources that are relevant. So if you get back just the raw version of a node, you also get back with it, and here's the URL to go to HTTP, put a new version of it. Here's the URL you go to HTTP delete that node, and various other things like that. I would very much like to see that. I don't think that's technically part of the routing, but I do want to see that, and that's a big part of the discussion about what sort of canonical format we want to have for serializing entities, because OData supports that, but has some licensing issues. JSON-LD supports that, and that one's quite interesting because it's used by Create.js. There are other formats, but yes, having that kind of restful linking, is something we want to do. Details, join the discussion on GDO, and let's figure that out. Cool, okay, yeah. Arguably it's analogous to local tasks too, and tabs, and arguably. What we do with local tasks is usually the kind of things that belong in that, but may or may not get done that way correctly. Yeah. What time does this end? Two. Okay, we have five minutes. Okay. Five minutes. So let's try to move fast. Yes, move fast. Okay, mine's somewhat related to Ethan's, I'm a tech ninja. I started the failed rest standards initiative thing that kind of got merged and stopped. Anyway, my question was like, so on a given request to a page, a page router says, okay, I'm gonna go get these blocks to fill in the page content. Are each of those actually separate rest requests within the page, or? Only if they need to be. Only if they need to be. Those are internal requests. So if you're operating in a single PHP process, then we create a fake request and render it and the system can handle that and the block is none the wiser. That's one of the things that we get from Symphony is it has that capability built in. If, whoops. If you instead have varnish in place, then that sub request logic happens in varnish and so Drupal gets hit several times and does a smaller task each time it's hit, that's not something that a block should know or care about the difference on. Yeah. Because you want basically a page requesting its own blocks to be exactly the same kind of request that you'd be getting for something else entirely going and requesting just a single block in whatever format it wants. Which does mean also that if you have a block and you're throwing something into a global and another block later you're pulling that global and reading it, that's going to break. Don't do that. You shouldn't be doing it already. Global's bad. Yeah. Yes. I will also note, Fabian just locked out. He is giving a session tomorrow on Symphony at one o'clock. I do recommend going to see that session. I apologize to whoever in the core conversation track that's opposite, but I do highly recommend going to see that session as well if you're interested in the symphony side of what we're doing. So I had one question for each of you. The first one's about layouts and regarding responsive design. So building themes, for example, currently you have theme regions for which you put blocks and then you have the content region and I've always thought that that's... Can you talk into the mic just a little bit? Right. So I've always thought that the theme regions and the blocks and all that was somewhat overkill given that we have panels and how will that all play together and how can you build layouts that will respond to different screen sizes, for example, will that all be baked in? Sure. So I think the notion of exactly how we get to responsive layouts is still one that needs to be investigated a little bit, but I don't foresee it being this really huge issue. If you are allowed to mix and match multiple layouts on a given page, which may actually be very viable since we're discussing essentially embedding layouts as like I wanted this two column layout as my header and I want this two column or four column layout as my footer and I'm just gonna reuse those on every page I ever override ever. We have to make sure that those respond within the same types, same screen sizes and things like that. So there are definitely some considerations there, not to put you off, but I have a lot bigger fish to fry just yet and so I'm really kind of relying on people who are already very deep into the responsive's initiative and things like that within Drupal 8 to hopefully come in and help make that happen once we get there. Because they'll have done a lot of that work already for the layouts that are, for the themes that are already in core and my objective will be to break those things down into layouts so hopefully there is no extra work, they just work, but we will cross that bridge when we get there. So to an extent responsive design is all in the markup and the CSS and nothing we're doing should force you to do markup and CSS a given way if anything it will allow you more flexibility to do markup and CSS the way you want to by just providing a new layout plugin. I guess one thing I was getting at is from a user experience side, what is really the difference to a new user between a theme region and a panel and a block and all these things so if those could be integrated as much as possible so you could. A lot of those ideas are going away, there won't be regions and themes, I fully intend on killing the page TPL and we will depend upon layouts. Okay and quickly the second question was about routing and URL aliases, secure pages, things like global redirect that right now have to build a bootstrap many times to redirect you around and how will the routing system handle things like that so if you wanna build a module that has a person who has publications and things like that so you don't have to define thousands of different URL aliases and define these pages as secure and how will that all out work? I'm not sure yet. URL aliases at least in the first cut are not going to radically change, at least I don't think they will. What may be possible, the big problem with bootstrapping right now is you need to do a full bootstrap before you can ever call a hook. So if there are things that we can set up to do without hooks then we might be able to push stuff earlier. At the moment though the kernel does happen not until full bootstrap. That goes back to the how can we collapse bootstrap and make it lighter weights question which is something we both want to see happen but it's technically out of our scope and we've got enough things to worry about as is. So yeah, I'd love to see that get lighter but we're not directly working on that yet. Sure. Okay and it's 201 so this is the last question. We'll be very fast. All right question is with ESI. You guys mentioned varnish and the backbone stuff like that. Have you guys thought about engine X or other things of that nature? Because engine X has server side includes. Right. And I see no reason why you shouldn't be able to do that sort of thing. There's also H includes which are another client side approach. In theory we should be able to pick and choose which of those we use. That would be an implementation detail that we haven't gotten to yet. Okay. But yeah, I don't want to hard code it to being varnish specific but that concept of render one piece and assemble it further down the line. We want to be as baked in as low as possible. All right. Thank you. Whatever the actual implementation is. Thank you all for coming.