 let's get started. It's quarter after. We've only got an hour. So thank you for coming. Hopefully a bunch of you know me. I'm Peter Willanon. This is a core conversation. As I said before, the goal here is to have a conversation. So hopefully you guys will use the mic. You're welcome to interrupt me in the middle. Larry's here and I say things about like what I thought Whiskey was about and he will hopefully correct me and tell me which way I was wrong as the initiative lead because this was again I'm just trying to put it up here on the slides to start the conversation and have us think about where things stand today and where we want them to be in the future. So this is being recorded. People may want to watch it later if especially if it gets entertaining and we start throwing things. So please use the mic if at all possible there's one over there that said you guys should come up here and sit next to me. That's fine too. But let's make sure that your questions and comments get on the reporting for the benefit of everyone who's not in the room. So the you know the big context of this is the Whiskey initiative which was originally named the web services and context core initiative. And here's the goal. This was I just grabbed this from Drupal.org. The group said Drupal.org. And so we can think of the you know the biggest context as stated here was we want to basically rewrite Drupal such that it does a better job be basically being an API server in addition actually just serving HTML pages. And so that's that's a big picture context. That's where you know I think the Whiskey initiative was trying to trying to reach. And you know so this discussion kind of maybe you can say you know did we reach that goal to what extent did we overreach did we do things we didn't actually need to do to reach these goals. Those are I think those are all the kind of questions I wanted to have in this conversation. So later just became the web services initiative when I think context got replaced by the container basically more or less yeah to first order. Okay so context became plugins and the discussion if you have kind of but also the container to do some of the things that context was going to do. So but you know big pieces that fell under this initiative were using the symphony to kernel using the symphony container using basically symphony routes and towards the end eventually the session interface using the request and response flow to handle the whole routing and page request flow which is something that I think if you've used other you know Ruby frameworks or other PHP frameworks that are much more simple applications or that are designed to support like a REST API that's typically how they work you know you have or Java API is also you have a request object that goes through a flow eventually you construct some content you you build a response the response comes back through all those same methods and you and on both ways through you have a chance to work with it. So that's kind of this response request response flow and in addition to having the REST API in core we wanted to make Drupal a better consumer of REST APIs so getting a better HTTP client in core was also sort of I think part of this broad initiative. So there's a lot yeah this is a massive massive initiative and with some clear goals and I think then you know some fallout that wasn't necessarily all planned or all scoped but clearly like one of the most important things that had to be done for this was converting essentially the routing definitions in hook menu and if we decide we want to do it like Symphony does then we basically have to convert all of that logic into this symphony logic in some way. The symphony system uses route names when we're referring to a route instead of a path for rendering them or referring to them so that was a big sort of a fundamental change in how Drupal worked I would say and so there was a lot of hard work to do these things like we just those first two lines I mean the amount of work to do to achieve those was massive was years of work literally and if we count times number people you know perhaps you know man decades of work or woman decades of work so you know we had to convert all the page call back to controllers or at least wrap them in logic such that they appear to be controllers something new about and then as we sort of broke Drupal's existing system in a way or started to replace it there's a lot of fallout so having to go through and problem and build breadcrumbs in a different way because we could no longer pull the same information in sort of a hierarchical fashion out of the menu system we had to build a new menu system we had to build new local task local actions so this wasn't I maybe Larry can comment I don't think that necessarily all this was sort of planned but you know we sort of ended up being necessary for the entire thing to work when we have this fundamental shift that I showed you in the first line which is that we're basically converting from hook menu to routes so yeah we're doing that and now we've got all these other things we've got to make to work in that new system so you know the first sort of lesson learned maybe and I'll come back to these a couple times is I'm not I'm not sure we understood the scope of work that we were taking on and and that I think that's an important lesson learned here that if you really get a rewrite a fundamental part of Drupal there may be a lot more work involved than you first anticipate so I think there were some you know some developer experience changes and possibly really good ones in the sense that your hook menu was terrifically overloaded and it was often like I don't even remember what all the things do if you give me a particular example of hook menu I wouldn't actually tell you exactly be able to tell you with looking at it what the outcome is going to be in terms of all the things that are defined the menu links the you know contextual links local actions some of them are obvious some are less obvious so I think you know we had a great change here and that we sort of split up those concerns we now it's very clearly defined it for each of those subsystems you know where they're defined how they're defined what they're doing and we don't have this intermixing anymore so we have put here mm for my module so you know we now basically have the pieces that were all coupled together in that one hook that returned data are basically split out now into five different yaml files in a typical implementation and that's I think better you know but we could have done that in even Drupal 7 or in Drupal 8 without changing the routing system we could have made this split so that this we we had a nice side-effect of improved developer experience but I don't think that we should say that that the rest of those changes were necessary to to achieve better developer experience and just in case any of you don't remember what hook menu looks like you know it's it's okay it's an array there's you know nothing's very strict you have to know that you know this thing that would pass in the array like the number one right that's an array index into something else which happens to be the parts of the path and that percent node means that there's a function called node load and maybe several other specially named functions and you know they're just specially named functions are not really strictly controlled and as with hooks in general you can have named collisions you know so and then yeah type so this is a local task but I think it would probably also make a menu link what does weight do well I think that was only for the local task it didn't actually affect the routing part of it right so it's you know this was really overloaded and as I said you know a single line in here might affect many things and you didn't necessarily have the kind of control or clarity you know about what these were doing if we look at the equivalent in Drupal 8 now this is only the routing so this we know here this is not going to have any side effects all we're doing is defining a route but you'll notice like the route name entity node dot version history what does that have to do with anything we have some funny underscore controller underscore node access revision it's not necessarily obvious what these do it's not as obvious as defining you know a callback function there's no backslash D plus you guys know what that means well he does but right so yeah in this case we're actually defining a regular expression that has to match that parameter in the path so that's nice node operation route I don't even know what that does so you know I think we could say there was an improvement but but these things are still not obvious you know unless you work with them every day about what they're doing and I think we have some some real problems in Drupal 8 for developers or for people that are beginning developers especially which is in Drupal 7 if you looked at a call to URL function you would basically see a path in there and so it was usually pretty obvious you know like what link kind of link in my rendering where what link is that going to be on the page it was a lot more you know intuitive so and if if I'm rendering based on a route name in Drupal 8 and I see a piece of code rendering a route name and I want to visit that page in the browser how do I do that yeah so you grab the code base YAML files or use Drupal console to look up the route and find the path so it's you know it's a little more indirect it's not as discoverable right you can't just say call the URL I'm gonna copy paste that in my browser and then the inverse problem right I'm on a path in my Drupal UI and I want to know what route provided that path in Drupal 7 you know 50-50 you could grab the code base to find the hook menu entry it still wasn't I don't think that easy all the time but still a little harder in Drupal 8 there's probably tooling we should put into Drupal core to provide more debug information so that's that's a possible part of this discussion that people want to talk about you know if they have things already built or they have ideas about what should be in Drupal core again let's discuss you can go to the mic now if you have an idea and again just so you know compare those things so in Drupal 7 you have this URL function we call node 1 or we concatenate a string it you know it was pretty easy to explain in Drupal 8 we've moved you know in part thanks to Tim I think to moving using this URL object as sort of the common interface to link rendering because before that it was really a mess you know and it's not necessarily that bad we actually have this entity URI do people know about that so if you want to render a link to an entity you can put entity type slash entity ID which conveniently happens to be the same as the Drupal system path in most cases so there are actually you know ways to do this relatively easily in Drupal 8 but I think a lot of people don't even know that these things exist and what you would often try to do is try to do the thing on the last line right which is like I'm gonna spend the time to find the route name and now I'm gonna call this from route method and I have to you know use this completely non-intuitive route name and parameters and call to string on it if I want to string so again I think I think you know part of the the fallout we're still dealing with is trying to communicate to people what the best practice is that you maybe some of these you have shortcuts like using entity URIs are the things you should do almost all the time and that conveniently maps to something that looks like a path and and it's gonna be a lot easier for people as they start writing this code to use those there are I think at least in one or two cases important performance improvements that we got by using route names and I could tell you about this because I wrote the hacks in Drupal 6 and 7 that allowed us to not have to do this so much in Drupal 6 and 7 but in particular if we're rendering something from a route name or in this previous case if from an entity URI that's basically one step removed through a look up to the entity class or entity annotation to find the route name so it's almost as good not quite as good or if this last case we're directly rendering the route name there's no mystery about what we're doing we don't have to do extra work to do the access check so in Drupal 6 or Drupal 7 if you were trying to do an access check on a URL you would basically or a path you would basically have to run the thing through the entire routing system to basically find the access callback right and then check the access callback and yeah so there was a whole extra step there where you're trying to break down that path and find the corresponding route as we you know you might call it in Drupal 6 or 7 and in Drupal 8 again you have an immediate look up that makes this thing potentially much less work to access check so one reason why we didn't worry so much this about this in Drupal 6 and 7 was the primary use case for access checking rendered links is the menu link system and there's actually a special hack in Drupal code which is is sort of beautifully ugly the special cases node links and assumes that they're gonna work as node pages and therefore bypasses that whole routing part to find the correct route so you know it's beautifully ugly I can see classes grimacing what's even better is it serializes an array with references between elements in the same array and then unserializes it and you still get these like ref internal array references still work after unserializing it's really who knew PHP supported these things right so you know and and I think maybe the route name is in some cases a win for developer experience right so now it's very explicit which parts of the path are the parameters versus you know the machine name you know if you see just someone writing a URL they're not going to just write that it's either it's going to be in some format we very quickly say this is the parameter and this is either the machine name or the entity name and we're going to go look up the machine name of the route from the entity the other thing here that's been argued as being important when was that this whole system allows you to change things including reordering the order of parameters to your controllers and to change the path that a particular route renders to without changing the rest of your code and I've certainly heard about this as a goal Larry I don't know if you have any feeling about whether that was actually a considered an important goal or it's just sort of you know one of the things that was said was important later two parts of that using machine names instead of paths is something we just kind of inherited when we decided to use the symphony router because that's how it worked that there were people pushing to have that level of separation already and so it gave them that feature the degree to which we've taken advantage of that I honestly don't know but that was kind of a some people wanted it and we kind of got it for free along the way so cool well and it allows to have like multiple routes with the same path which we do for rest for example right or is that not yeah that was the other big thing we wanted was multiple routes on the same path that can branch on something other than just the URL which yeah you need some unique identifier then other than the other than the path pattern for that to work and did we necessarily need to put the machine names through the entire system quite as far to do that potentially not but we can talk more about that later at least regarding the last point and I think it's kind of pointless because if you went a link it is the same girl if it's if it where we buy something else so regarding the pure linking part of things it's a little bit of weak argument but I think in general and there's better discoverability in a way so well and this is what Larry just mentioned right that yeah we there is a win here in that yeah now we can have multiple routes with the same path because they have distinct machine names and in particular the HP methods having distinct controllers for different methods I think was very important to kind of this concept of making Drupal support a rest API right so we can certainly say that this this particular gain was central to that whole initiative and was clearly I think the whole community bought into and you know let's do other interesting things even beyond something like HP methods we could actually define routes that look like this like nodes slash bracket node which is a placeholder or a slug and in one case we could have backslash D plus which means it's out numeric and another case we could have you know something would match like a UID you know is that important you know are people going to use that facility in core or contrived I'm not sure but maybe maybe that's a win so you really can limit you know matching the things you're out really wants to match and you can ignore the things you don't really want to match and let someone else take care of it so yeah could we have done it differently I think this is maybe at this point it doesn't really matter because we are you know we're we are we are but you know just for for brief second we'll take a look back and say you know could we have as Larry said gone less thoroughly towards using you know route machine names everywhere and kept something that was more like a path based system you know could we have even used I think you could maybe even use basically the paths as the machine names the most part maybe maybe not but you know I think I think we yeah we adopted sort of this existing system and and again without necessarily considering the amount of work and fallout for other subsystems within core you know at this point you know maybe we should be focusing on educating people in the best practice they should maybe use these entity your eyes or Daniel suggested we should maybe even have a more compact format or just somehow better support a simple path based linking for people let's say in twig templates or some place where they're not access checking they want to link to some page on the site they don't really care they wanted to always be there but they want to get the path process saying they want to get the language prefixing they want to get other things that come as a side you know benefit of actually using the correct link rendering system so maybe there's a way we need to make it easier for people to do that without them knowing a special you or I prefix that you have to put in front of your path to make it work I think we should definitely do that because it decouples our routing system from the template systems and then in case we ever want what would like to when does stuff in JavaScript I mean we don't want to expose the routing system into intertrick so something yeah I agree that have the entity your eyes are a good abstraction that helps you know it helps that separation I don't think we want to go back to putting raw URLs into code because as soon as you do that once that becomes another place you have to update it anytime you want to change or even consider touching that URL again it's not something we necessarily do often but there were contrib modules in D7 Chris Van Der Water if he was here could talk to that in a lot more detail where he was actually you know moving pages around on the site from a module which you can only do if that path is fully abstracted to the route because then everything links to the route you can change the path and do all kinds of fun stuff there so there are things you can only do if you fully banish paths from the from the code base that said alternate URI formats that also provide that same abstraction level that makes a lot of sense yeah well I guess that's the hard part because for the average theme developer let's say like they may not understand the abstraction and but they know exactly where they want what URL they want to link to so I mean there is I mean there are people building like two besides without the double thing and I mean they they built the the theming aspect first or separated to the actual two besides so there is no quoting there right yeah I guess that's yeah in that case you wouldn't really have advantage of the path processing or something but certainly yeah heard of people building essentially static sites or a theme that you know essentially renders the full site you know before yeah they put any Drupal content into it so I think the idea with using the path as the machine might not be too bad right because we need to make up and identify and and currently for this node example here this would be entity node something I don't know and if we make the string up anyway we can just use the path and for most of the routes it will work because there's only one route on the path sometimes we have multiple routes on one path so we need some suffix or prefix or whatever but it's still a much better developer experience because you immediately see where that URL goes to so when somebody reviews the code they have an idea what's going on I mean it's really because I mean one reason why we have this entity dot entity type dot canonical thing is that we can generate paths or generate while it's automatically and yeah the other downside to me to using the paths is then you don't know which one is which if it's a path or if it's a route name especially if you don't have a slugs in it it can get very confusing very quickly the only place I know that we still use paths for things or tests and that doesn't bother me because it's okay for test breaks because then it means you need to fix your test well at least regarding the point of uniqueness I mean the slash pretty much indicates it whether that's a path or I think in practice most of our hard-coded routes have a machine name that's more or less based off the path anyway in practice and as Daniel said the the route the entity routes have a specific naming format because there's a lot of automation built around them but for just an arbitrary path you're sticking a form somewhere all of mine are basically you know the module name dot path with slash is converted to dots and that works fine so that it you don't have to think that hard about a route name when coming up with one and if you are then don't you don't need to stress that so it's about it that much I mean specifically when we're talking about linking to something we actually have like these internal URIs so you can actually like not saying whether that's like a good or bad thing or a good or bad idea or whatever but like it's actually possible to just link to a path so like we could actually have linking be completely separate from the discussion of whether we need route names or paths as route names or whatever so that's true but it's entirely not obvious for like a theme developer right how to do that well there's actually two different ways to do that right so one is the internal scheme and one is the base scheme right and yeah there's maybe more and those one of those will check access and apply path analysis and another the other one won't and you know which is which one do which right I've long said that you need to be like a senior developer to generate a link and I mean it's true it's actually true like with all like if you want to know everything about link generation then you have to be at least senior level like at least part of the reason for that you know Tim just noted over here that there's nine different ways of generating links most of the reason for that is not the routing system per se it's other systems that were in development in parallel and as soon as link generation ran into the render caching system everything broke and so the end result we ended up with that makes things work with both routing and the cache system is you know you your eye objects with abstracted values that get rendered later because then we can track their cache contexts for things that may come in via a outbound URL path processor that alters an old an arbitrary link and it just gets weird Drupal's contexts you know Drupal does all kinds of crazy things in crazy places so the reason there's so many layers there is we kept trying to abstract it enough that to stop breaking caching and by the time we finished we didn't have time to convert all the others over anymore so there was a discussion at the last Drupal con about okay there's two ways you should be using let's just get rid of all the others I don't know how far it went since then but we did have a meeting about that so hopefully we you shouldn't have to be a senior engineer to make links in the future yeah so I think yeah that may be more than methods that maybe at this point more the Drupal 9 discussion one concrete suggestion what we could do I mean often like there's one really weird thing which is entity to URL like why why is it the other way round and so I think we should have URL from entity and you can pass in the entity object because that makes URL so the primary thing and it also takes takes into account the fact that entities are one of the most important things in Drupal okay so the core patch we'll be working on on Friday so you know I think one of the other you know things we talked about it as an important feature right that we using route names allowed us to match at the same path different HP meta methods and we also originally had a concept that we were going to do header based content negotiation for the response format now in the end it turned out that we threw that away basically it's still supported by core but it's not used by core we switched using query parameters for content to negotiation because in the real world there are caching proxies all over the place and they don't necessarily read the headers of the request and they don't actually give you back the content that you asked for and if you're using Safari it's broken Safari is the reason we can't do this even when you control the proxy server so screw you Safari yeah so you know so this is you know I think at one point was a a significant motivation for our for a routing system where we focus on the route name and again have many paths many of the same path that can could resolve but you know so I think a little bit looking back you know question could we have done it differently could we have enabled multiple routes at the same path let's say in Drupal 7 with much less change could we have you know suffixed the path name with the HTTP methods that were supported or something if that was the sole use case was was making that to a REST API more possible and as Daniel said when you're rendering link you're always basically rendering a get link so in that case it wouldn't really have mattered that much so you know I think looking back it is it's hard to say what the you know so what is the lesson learned here I think the that conversion of path throughout I said create a lot of sort of unplanned unexpected work or work that wasn't realized or was underestimated maybe when when it was first proposed whether or not it extended the Drupal 8 release I could say yes to be provocative though I think what's interesting is you think about the like the dynamic page cache you think about auto escaping and twig a lot of those problems were also not actually solved until last minute so that it's unclear if we had refocused the effort of the developers who were working on routing and menu related things would we have solved all the sooner or do we simply need you know a lot of development time to get those and in a way we sort of got Drupal 8 and a half you know because we finish those efforts by the time we got Drupal 8 done and so I'm not sure you know so if we had said everything was done sooner and we didn't have those other features will we have gone ahead and you know enable them in what would have been Drupal 9 maybe so you know I've already mentioned this that yeah we might have we might have done things more easily I don't think at this point it makes sense to go back so but maybe in terms of when we looking at some Drupal code that is well well established we need to think harder about what the impact is of changing that especially that has side effects and in the end we actually ended up using the Drupal algorithms from Drupal 6 and 7 essentially behind a facade of symphony interfaces because what Drupal did was beyond the scale of what a normal symphony routing system would handle so to me it's a little unclear whether whether it was really a win to adopt these components because we ended up having to essentially just use them in front of our resisting algorithms and so maybe we could have shortcut those code pass a little bit or maybe we still could so that's certainly one thing I think we should discuss is like how much of the using that symphony system is critical now how is there part of it that we could you know short circuit or reduce or make more compact and both in terms of the sort of developer experience of understanding how Drupal works and also in terms of possibly performance the other thing in terms of we know where we go from here is there's probably a lot of work left if we actually wanted to convert you know a hundred percent of references to paths to route names or any your eyes as Tim mentioned probably the vast majority of what's left is in test cases and in a lot of cases you know for the test it's not a big deal of it breaks so maybe this is work that could sort of be deferred almost forever or you know made as you know novice patches for someone who wants to just cut their teeth the other piece I think that we don't know yet and maybe people here have feedback is are there going to be sites or their contrib modules where people really want to take these you know existing routes let's say then you know so the use cases like the node route and I instead of node I don't want the word node to be my URLs anywhere I wanted to always say content or I always wanted to say some word in your preferred language that describes content and so I want to go in and I'm going to alter all the routes and I'm going to change the path and that should be possible but are people actually going to do that or again if the case the module refactoring is now the module refactoring where I need to change the paths but not change the route names is that going to occur often enough that it's really an important feature or if we went to rendering you know and sort of made it easier to just use the paths would that be that much of a downside in the long run so I think that's you know that's certainly a point if people have opinions on I'd like to hear your opinions or what you've done so far with your modules or your sites are people using these these features another important feature we have right is the case that we're loading you know all the possible routes that match a path and then we're basically filtering them down to the one that we say is the best match that's how Drupal the Drupal 8 system works which is sort of adopted more or less I guess from symphony loop so you know so possibly that's going to be important for things like panels and Drupal 8 because now we have for panels that means that's an almost native way for it to support page variants right so it can have many different routes for the same path it can look at the incoming requests you can say what's the variant the route that should match this and now I have a very clean and you know way to do that that that is within the API and not sort of rebuilding the whole API hopefully they will choose to do it that way and not rebuild the whole API but at least it's possible or you can think of other projects where yeah again if you have these variants or you have sections of the sites that should behave a little differently for nodes in this section of site versus nodes in the other section of site now we have a little bit more built-in support for the notion that you know the same path could end up being rendered differently or or rendered by a different controller so and to the extent that those things are important you know can we cut down the code can we make it more streamlined without losing the you know sort of that important feature so I think that's you know these are sort of for me the questions in Drupal 9 that there's you know I don't I don't see it as feasible at this point to go back to what we had because going back to what we had would be so much work that we would just all give up and I don't know what's what's the new framework today we'd all take up Java I mean it would be that bad but you know this is this is kind of you know I was looking just at like the call stack to get to the point where we actually do routing in Drupal 8 this is kind of I think what the call stack looks like for an authenticated page request and this isn't this is the actual call stack not all the function calls that happened and if this is only to the point of where we were starting to build the route collection we don't even this isn't even getting the route filtering and calling the controller which would have been you know that much more so to me it seems some of these things I think are fine and you'd we don't really need to optimize them so the middleware in particular if people are familiar with the concept of middleware I don't think that that's problematic to be in the call stack because it's very easy to describe to people like the role the middleware plays and how to basically go from okay just imagine there's no middleware or imagine we pass through all the middleware now what's next in terms of documenting or explaining the routing system but I think we then get to a little trickier system where we have multiple levels of routers and we're using you know this kernel event and basically I mean I understand that's the way Symphony does it but I think it it means it's well on the one hand you could replace this whole thing with your own system so on the other hand do we need that level of flexibility and did we need to follow that model so there it looks like yes wants to say something about that so couple of points I can I'll say on that I'm not going to disagree with you necessarily what I'll say is one of the reasons that we use the symphony system kind of as is in a sense it was quite frankly to shortcut the bike shed because this gave us a existing architecture that we could say all right these decisions are already made we're not going to argue those we're just gonna argue the next layer up and I felt that would and I think did save us a lot of debate time because we could just use an architecture off the shelf even if it wasn't perfect it was still something that would work and clearly it does work could we simplify pieces of it now after we get a better sense of which you know which flexibility points are actually used probably I think another advantage you were talking about the the scope question of you know just how much did we have to change it was impossible to know before we started precisely because so many systems were implicitly coupled to each other and one of the big wins in Drupal 8 is things are less tightly coupled and where there's overlaps it's more obvious so you know were we to try and say okay now let's make some major surgery to the routing system it'll be easier for us to figure out just what the scale that is the way Drupal 7 is architected everything spidered into everything so much that you know pull a wing pulling one thread everything turned out to be attached to it that's why loosely coupled or fully decoupled components that you can mix and match adds more architecture for those seams between them but gives you the ability to rip out pieces in a more controlled fashion going forward so yes it was painful yes we probably still need to iterate on it but I think we're in a better position now to iterate intelligently than we could possibly have been before so that I still think was a step forward there are definitely still more steps forward to take I just want to say I think the conclusion you just said is spot-on but I think the beginning was was not there's no way that you can say we're gonna replace the routing system and we don't know what it'll affect if you look at a single hook menu definition like we know there are eight things in there and we knew in our inner minds that we were gonna have to fix it all but no one want to say that loud because then none of the police managers will less change the routing system because it would have taken five years which is like what it did but saying that we didn't know what it would affect is just bullshit because Daniel I did all the work that Larry started anyway I wanted to go back to that slide here as you said like the middlewares sure that they are kind of optional but then there's a this thing called X is a wear water chain water chain right a dynamic water nested match up and that's yeah I think we should improve it it is I mean the coupling code or your architecture is really nice is in the case where you actually have a use case to replace those components I doubt that anyone in the room ever replace the routing system right I mean theoretically that's possible but in practice it's basically impossible because access checking and authentication and everything so I think we should maybe collapse down at least three or four those things just on the scope scope issue again I think you're kind of right that it was or I mean I want to disagree with him to a certain extent I think you're right that probably people knew that this was gonna be like a huge thing if we just like rip out the entire routing and write it new but I don't think that anyone like I don't think it was that we just had it in our head and no one was like or no one was daring to say it or anything I don't think anyone was aware like specifically of the things that we were going to encounter like then like two years after we we introduced symphony routing people notice that we don't have like the menu tail thingy or that like with all sorts of language stuff that that ended up being broken like years after and stuff like that so I don't think we ever and I think that was a pretty big mistake that we never actually got to a point where you had like a a plan like scoped out so this is gonna be how it's gonna like these are the steps that we need to take and I also think that that was the reason that we basically had to like port Drupal core to the new routing system like five different times so at first like we created all the routes and then it was like underscore content and then but then we changed back to underscore controller but then some of them act to underscore form and then we have underscore entity form and then access changed and then we had like options and parameters and then we just remove them again because we can auto generate them and this is like just the routing file like there's and like each of those steps sort of made sense each like when you look at each one of them but I think there was just an immense amount of work that we basically just lost of people over and over converting like these huge chunks of core to an API that's like obsolete two or three months later and actually want to like I thought about this a little bit and I think the the new semantic versioning that we now have kind of gave me an idea of that we can maybe learn from that because now we can add the experimental modules and like have it in the core repo and like let it mature for a while before we like say okay this is a good thing and I don't really think you can put like routing in a module but maybe we can find a way to have things in core and just let them rest or let them mature for a while until we say okay this is good this is going to work for a couple use case and we're still going to refactor it maybe once or twice but maybe not ten times yeah and I want to say one other thing like in regards to the to the URL generation and like maybe routing in the future in general I think actually with with the entity stuff we can see that it's a really good thing when we move away from like especially for DX and for themers and module developers when we move away from like these low level concepts of I have a page like I have to write the routing ammo I have to do this I think it's better if we move towards I mean the entities like you have an entity and I want to link to the entity and have another thing like a config form or whatever I want to link to the config form and now the config form has a menu link somewhere and so I have like this kind like a smart config form whatever object that has like a tool URL or like I don't care about the actual API but I think in general it's a good thing to to sort of find semantic higher level concepts that make it just the code more readable and make it easier for everyone involved another thing is I wanted to say I think we made a mistake in the way how we converted things and so assume we would start on the left side that status quo and right side is our end goal we start off kind of started to fix stuff on the end goal side but then like had nothing in between I think it would have been much better on like in that was in retrospective to actually come from the left side and continuously improve until the end so I completely agree that we had a ton of wasted work over the course of the cycle so my apologies to anyone who was involved in any of that I will however point out please remember this that's five years later our processes are a lot better there's still a lot of problems with them but we actually have semantic versioning now we have dates Drupal in 2011 had no clue what its timeline was had an active opposition culturally to big plans and wouldn't accept a proposal until code was written which meant just convincing people hey we should do X that's you know a step towards you know things 15 steps later until we had that 15 steps later things people to look at nobody in a leadership position would accept even step one we ran into that ton the first year of the whiskey initiative was spent trying and failing to convince people yes we should actually do something so you know a lot of that were not technical reasons but process failed reasons in Drupal many of which have improved since then some have not I do think the new round of initiatives are being run a lot better than the Drupal 8.0 initiatives were in many ways because of the bruises and bloody messes that the old ones left behind you know a lot of it was simply the way core development works or worked you know limits what you can do and we tried to have larger step-wise plans and do this thing which will support this thing which will support that thing and we got told no so hopefully we'll do better in the future about having planned that week and roadmaps we can actually deal with we've got dates now we've got more people who are paid to work on core now which is wonderful because now we have predictable resourcing at least more predictable than we did five years ago which also makes it easier to say so how much work can we take on none of the initiatives could answer that question now the new initiatives can answer that question or at least make a educated guess so that should be a lot smoother going forward whether that's you know workflow initiative migrate or you know routing D9 initiative whatever that becomes I think there was just a core process proposal that is more almost accepted of trying to create a new issue queue for large scale plans and large architecture discussions and getting those signed off before anyone actually starts making patches yeah I it's like the fourth or fifth iteration of attempting to get approval on a concept before someone writes code which we desperately need as a process to avoid that kind of waste so hopefully these process issues will improve and that will give us better and more efficient code development so almost to the end of the slides here and I'm glad that we had discussion throughout as opposed to saving it for the end so as we said maybe we can reduce the overhead on the router maybe we can you know compress it or remove some components I think the debate there is going to be like which of those things count as being you know we have to have for backward compatibility versus which ones are internal details of the API and people shouldn't complain too loudly if we you know juggle the internal details you know and I think in terms of performance hopefully we could make that a little better you know I certainly remember writing the you know in the Drupal 6 code initially that you know every single function call Dries looked at personally because it was in you know the critical path to delivering the page and you know now we have a lot more code running we haven't had that level of scrutiny and again maybe that's in some ways good because we allowed us to decouple the pieces they're not as you know closely intertwined but I think a problem it certainly remains right now is that this this you know call stack is not really what that well documented on Drupal.org I think even like for myself like trying to step through it with a debugger I very quickly confused about like what's actually happening at Whitpoint in the process in terms of sessions authentication you know when you're building the response when do you actually figure out which route you're you're taking and so I think you know to an extent that simplifying that code path would would make this easier but even if we don't simplify it we need to do a better job documenting it and giving you know people sort of a high level understanding of the of the different steps and what they're doing and why they're there you know and you know in terms of improving performance I think there's maybe symphony code we're using that we don't need you know so our database query basically matches all the fixed strings in the path and then we go into a symphony compiled route and we run a regular expression to match the fixed strings in the path you know there's there's things like that we could probably cut out it wouldn't really affect the API or the developer experience but it might improve performance or reduce the number of you know regular expressions and things we're running in order to find the right the from the right route so that's all I have we can certainly discuss some more but yeah we may if you guys don't know about sprints on Friday hopefully people coming to this kind of session do certainly please come on Friday and come over the weekend to the extended sprints which were a lot of fun last weekend and evaluate this so that people think that you know I had something to say and wasn't just trolling Larry so thank you and we have few more minutes so you don't have to leave but yeah so for Drupal 8 yes I think we can do some simplification as long as we take a narrow definition of what the current API is I think there are plenty of things we can clean up there for Drupal 9 I'm going to open a can of worms and say for Drupal 9 we should be using PSR 7 natively mic drop to explain what that means cuz so right now we're using the request and response objects defined in the symphony HTTP foundation library and the symphony HTTP kernel PSR 7 is the framework interoperability group specification for request and response objects and there are middleware standards coming out from fig soon they're in development now that a large number of other projects are adopting basically HTTP foundation was the PHP request response version 1 PSR 7 is the PHP request response version 2 that almost everyone except symphony is now adopting symphony may or may not go that way by symphony for that's a very open question at the moment but I think by the time you since Drupal 9 is still several years away I would like to see us when that actually happens switch to a PSR 7 based pipeline which may or may not entail removing some of the symphony components depending on what symphony does in the meantime but I think you know speaking from the perspective of decoupling an interoperability win in the future that is where that win is is with the fig based HTTP handling which I don't know what all the knock-ons of that are going to be this is why if you're not doing routing you should not be looking at the request object yourself don't look at the request object and you're insulated from everything I just said one comment regarding that like is there any way to do that in BC compatible way like I mean we don't want to convert everything again rather and instead we could like have a smooth transition and slowly convert things over like doing that the eight cycle and then like the nine would be just bump we just use PSR 7 instead of what we have at the moment yeah I think there's some kind of adapter right so you could maybe give a controller that needs the symphony request to get the symphony request and we already have that that made it in so right after PSR 7 came out symphony released a bridge library that can convert back and forth between the two and we snuck that into the last minute in Drupal 8 so as of today if you have a controller you can type into it it's signature to get a PSR 7 request object and you can return a PSR 7 response object and we handle the conversion at that level ideally we'd be using a PSR 7 object all the way through that would mean you know we could put the translation in an outer middleware and then have PSR 7 middlewares and then found HTTP foundation stuff in the middle but then you might have to convert back and there is a cost every time you convert so maybe it depends how much we're willing to convert of the other stuff the other thing to keep in mind is that the symphony request object and the response object are mutable so you can use them as a global variable essentially the PSR 7 object is immutable so while you can still attach extra metadata to it just like the symphony one you can't just stick it in the global and access it like sticking to the container and access it like we do now so there are some things that it by design very deliberately keeps you from doing with a request because you have no business doing it not that that ever stopped us in Drupal so there there are probably ways that we could you know stage that transition but there are large chunks where it would be highly problematic like anything using the symphony kernel events needs a symphony object not the PSR 7 object. One thing we maybe should also do for Drupal 9 is to look at HTTP2 and whether we could leverage that somehow in our system to improve performance another thing is we kind of really struggle with streaming stuff so for example big pipe is streaming constantly it's HML and it's data out and HTTP with HTTP foundation is really not the best tool for that maybe PSR 7 helps maybe it doesn't but in case it doesn't we should maybe check out some other solution because it's kind of problematic especially because I think the world moves more towards streaming in general. Okay well I think we're about at time so wrap up so we guys have time to get to the next session but thank you for attending and thank you for all the discussion