let's get started. It's quarter after. We've only got an hour. So thank you for coming.  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


Welcome to Drinks Made Easy. Today we're taking a look at a chief Lapu-Lapu variation where we substitute grenadine for the passion fruit. Now, there is no disputing that using fresh passion fruit is the way to go. But sometimes it's out of season or your store might not carry it. Or maybe you can't go to the store because you're too busy doing a really bad haka dance. Sir! Oh my god! Where did you get nanny cam footage of me?  She worries. That's just...weird. To build your chief Lapu-Lapu variation, you'll start with 3 quarters of an ounce of white rum. Next you'll add 3 quarters of an ounce of dark rum, one and a half ounces of fresh orange juice, one ounce of fresh lemon juice, and three quarters of an ounce of grenadine. Cap that off and do a shake or tin full of ice, and give it a good shake. Next you'll pour the entire contents into either your tiki mug, glass of choice, or in our case, our improvised pineapple mug. Which you can just use a pineapple core and spiralizer, an easy peasy. You've got a fun festive mug and you're good to go. Because a mug like this is going to be a bit larger, make sure to have a little extra ice on hand and just top it off. Next we're going to garnish the drink. And one of the things I like about tiki is it's kind of the more the merrier. You can overload a drink with garnishes. And in tiki, it's all fair game. So we're going to do 3 little pineapple leaves, a little umbrella, fun little swizzle stick, and of course this drink isn't really complete if you don't have something to drink it with, so a straw. And there you have the chief lapu-lapu variation. Thanks so much for watching. Please be sure to like, subscribe, and click on the bell icon so you'll be notified anytime we release a new video. If there are any tiki workarounds that you need help with, or any beverages you'd like to see here on the show, please leave a comment. And as always, drink responsibly because everybody likes to make friends, but nobody likes to make them in a prison shower.


We're going to go over basically how we manage data at BDRC. I'll do a very short introduction for everybody just to our organization and what we do. And then this, you know, I was talking to Nathan about this is kind of interesting kind of perspective or angle this conference because it allows us to talk a little bit more of a higher level about how we're actually managing all the data and what kinds of data, what we need by data and the types of data and so forth. This is an 18-year project. So we've created a lot of data and all the issues of scale and workflow and all those things. We've made all the mistakes and struggle for many years, especially in 1999 and the dark ages of the internet. So it's been, so we want to elucidate a lot of the methods that we've used in terms of how we manage the information, what kind of information we're talking about. This project was founded by Gene Smith in 1999 as Tibetan Buddhist Resource Center. In 2015 we changed our name to the Buddhist Digital Resource Center. It's going to expand our impact and the kinds of material we're working in. We focus on text, textual resources and metadata. We don't get into audio or video or anything like that. So basically what we do is digitize source material through partnerships or through our own digitization programs. We scan centers, field, we do a lot of field work and then we curate the source material using scholarly validated meta-data, it's an important part, it's a major interest of genes, not just standard library cataloging but more scholarly validated documentation. And then we make everything, we preserve, make everything publicly accessible and also back things up in a long-term preservation platform. So our current status here you can see down here, this is year 2016, this is millions of images. So we're at about 13.6 million images primarily in Tibetan but also increasingly in Pali, Sanskrit and Chinese. And we also, our website is a global platform, 200,000 online sessions a year and we just released an app, an app store, an Android and then everything we do is preserved in Harvard DRS and I'll go through a little bit of what that means. What kinds of data are we talking about? Digital text resources, you could say digital assets, those are the assets we're managing and then metadata about those assets and then source code. Ellie's going to talk about metadata and source code. Source code actually is where there's a lot of business rules, what's called business rules and software development that are implemented in the software. They're not in the metadata, they're not in the resource that you're managing, they're implemented in the source code and so you have to keep track of that as well and where those business rules are. So these are kind of digital text resources, images of text using open source standard formats as much as possible but also page transcripts. I'll go through a little bit about how we use TEI, issues with TEI and then our multi-layer architecture. So types of data here, metadata also, documents that describe digital assets. The metadata itself becomes so rich that it becomes, even the definition of it as metadata starts to blur. This is data that's worthy in and of itself of curation of sorting, storage and so forth. So metadata is critical for accessibility management and preservation. And then also the source code, manage the digital assets, there's a whole apparatus of software that manages all the digital assets, makes them discoverable, organizes them and archives them and also connects the metadata to the digital assets and makes them discoverable. So scale, I've heard a little bit of discussions of scale. Scale for us is critical. It impacts basically every decision you make, what metadata format you use at all, how much metadata you put into, how much metadata you actually use, workflow systems, how you visualize and present information if you have like faceted browse, if you have 40 texts, there's a limit to the amount of information that the user will see on the screen. If you have 450,000 texts, it's a very different scenario. So the scale is really important and it really defines how you implement what you're trying to do. So our scale is that actually 13.6 million images. That's actually 31.2 million total digital assets. So that's all the web delivery images but also archival images. And then page transcripts, we have 17,000 text documents. So that's the scale right now of what we're doing. Scale of the metadata, 160,000 records, items, persons, places, topics which equals and we'll go into, Ellie's gonna talk a little bit about RDF, that's about 10 million triples and 450,000 individual work objects. So that's out of the items in the library, it's about 450,000 individual works. And the source code, 220,000 lines of code in our current platform and right now we're developing an open source platform and Git, which is GitHub, which is 25,000 lines of code. So I'll talk a little bit about data management of the digital resources, kind of get into the weeds a little bit because this stuff matters when you're at scale, every single thing you do in terms of how you name your files, what directory structure there is. We've had four major migrations of our whole digital archive. So now we have a mirrored architecture, local storage with web deliveries on Amazon, web services, AWS and S3 buckets and backups. We have RAID 5 for local storage, actually mirrored, so it's actually four backups. And then it's also mirrored at the Internet Archive, we're building that platform right now and then our long-term preservation backup is at Harvard, so I'm just kind of rifling through this stuff here just to give you a sketch of what we're doing. This is our architecture. We have the local storage here mirrored to S3 bucket and AWS, which is made available, will be made available through a IIIF service to image clients directly or to a whole series of applications. So we spend a lot of time with software development and we have five software developers now. So yeah, that's the scale of what we're doing. Directory structure, it's like, these are item IDs. So when we started, we had a couple thousand images and then we had 10,000 and 100,000 and then a million and at each time things started to break and we had to kind of keep track of things. So now everything's in S3 and it's quite nice. This is totally unique. We had to break up this long list of directory structure into buckets. So this is very stable now, all unique. Down to the individual TIF number or image number. Who did the presentation on the file naming? Okay, these are rock solid and unique on the internet if you take the whole path. So policies, how do we make stuff accessible? Big thing we worked on is we differentiate license and access. So we worked with a copyright activist at the Harvard library who is very much obviously has much more of an interest in making things accessible than restricting them and kind of concerned with cultural heritage projects that are using copyright in ways that aren't necessarily appropriate. For instance, if you have an image of a public domain text, that's not copyrightable. The image is not copyrightable. So we have about 75% of our library is in the public domain. So we had to deal with this. What we were doing before is we didn't have a mechanism to restrict access. So we copyright restricted. So when we went to Harvard and said, well, we want to give you all of our scans for long term preservation, they said, well, what's the license on this? We said, well, it's copyright. And then you do a copyright analysis on it and it's like, well, no, it's not copyright because that's a public domain material. We said, well, the people that gave us the text don't want it publicly accessible. So then we needed to find a way to differentiate between the license, the legal designation of the asset, and then it's access. So we came up with this, which is separating license and access, public domain and copyright, and then a set of cultural restrictions based on the owners of the traditions and what they want restricted or not. This is very managed by us, basically, and it works to a certain extent. A lot of people want these texts, so we do not have a very strict way of providing access except basically you have to contact us. Accessibility, we have a whole web application framework for serving up images and an authentication for access control. So I'll get into this. Actually, how much time do I have? Okay, so Ellie's got to talk to you. So not only scans but transcribed texts produced from OCR and transcriptions and digital editions. So our current e-text repository is in TEI. So I am not a proponent of TEI, and the reason is that TEI is very strong semantically but it's expressed as XML. So you can imagine a case where there are different XML formats. So how do XML formats overlap? They don't. So the most simple semantic breakdown is of a page. So if you have a page and then you have an outline that breaks, that goes across the page, it's very difficult to express that in XML. So you have a lot of workarounds with non-breaking tags, milestone tags. And in our case, with 17,000 documents, it's very difficult to manage different text documents that have different TEI customizations. So the interoperability and the lack of overlap of XML. So our problem with TEI is not that the semantics of TEI, it's actually the XML of TEI. So kind of a way forward where you use the TEI header as metadata pointing to basically the TEI body, which is the asset. And then the tags in the TEI body encode the character position in a text stream. So this is our multi-layer architecture, which looks like this. You have the metadata and a linked data get repository. And there's a base layer, which is just the ID and a stream of text. And then we chunk that up and serve it up to our search engine. And this is our search application that's written on top of that. So this scales for an infinite number of tags. And then we have, this is actually under the hood, you do the same things if you have language analyzers which look at different languages, and this is using the Apache Lucene framework. So the multi-layer kind of looks like this. You have basically a table structure here. And then you have a JSON file here. Actually, this is turtle. And you can't read it, but basically it says that this slice number is on line one and the start character is here and the end character is here. So you can basically, these are all layers that point in to your raw text. So what we want to get, how we're doing this is that you're going to have text files which are raw text and your layers point to the raw text. And when you do this, you can have an infinite number of layers pointing to the same base text. So there's no collision. And then there's semantics involved with each of these, each of these layers here expressed in this RDF file. So that's our multi-layer architecture. And then, okay, so metadata. So Ellie's going to talk a little bit about metadata. Yeah. Okay. So what I'm going to talk about is the way we design our metadata in our new platform. So it's quite, it's not finished yet and it's not what you will see on the tbrc.org website. So first, due to the scale of the data and our idea of a semantic network within our dataset, like all the entities should be linked together and also linked to other datasets, we think of our data as linked data. So what it means as some core requirements is that every resource has a persistent ID in the form of a URL. So this URL you see is, for instance, the ID of a jingling by the tibetan person in our database and it will stay there forever. Also the data needs to be served in a standard format, like JSON, SNL, et cetera, and with a standard vocabulary. And the way to do that in terms of technology is through RDF. I mean, RDF is a format that's been designed for, to meet these kind of requirements. And so that's what we do. So we use RDF to have persistent IDs and standard formats. And for the standard vocabulary, we have design a role, which we call the Buddhist Digital Ontology, and it aims at being a standard for, in the Buddhist field, so that any other project can use this standard or at least convert this data to this standard and link to our data in a very semantic way. And so that's work in progress. We are documenting our vocabulary and we are hoping to release a final, maybe not final, but at least a public version with some documentation, maybe in January or February. So now in terms of the data themselves, we have different documents like one document per person, per work, per place, et cetera, which is in RDF. And we serialize it in total formats. So it's a standard RDF way of representing a file. So it's human readable. It's plain text file. And it's uncompressed. And thanks to these properties, we can have these different files in Git repositories. So this allows us to have versioning of all the different resources and also versioning on the type level, like we have a Git repository for the persons, for instance. We have sort of a version for the whole data set of persons, which can be quite convenient. And it also solves the backup problems because you just need to clone your repository on different servers and you will have all the repository and all the history of all the resources on different servers, so it's backed up very easily. All our Git repositories will be available on GitLab.org, so it's sort of a GitHub platform. And so it will all be publicly available and you will be able to access it for free. And one aspect which is interesting also with Git is the human readable disks. So if you want to see what changed between, like, two days or one month, et cetera, you can see that very easily because turtle format is very human readable. And so when you ask Git to show you a diff of all the files, you can see very easily that, okay, this property changed, this name changed, this name was added, et cetera. So it's quite convenient to see what's going on. In terms of access, for the read access, all our data or metadata will be under CC0 license, so basically kind of public domain. And there will be, of course, the Git access if you know how to use Git, but also public interface that you can think of as an enhanced version of TBRC.org with more features and more semantic search. In terms of write access, only our staff can write on the data. So that's the current system, but we want to, let's say, make it more flexible through a mechanism called annotations. So I mean first the general idea of annotations in our metadata is that every piece of information and every, even this person has this name, this is one information that we want to be able to annotate. And also even the region of an image or a set of images or a region of a text, et cetera, we want to be able to link all that and annotate all that. So for instance you could say you could use annotations for provenance indications like, okay, this person has this name, and you could annotate that saying that this person has this name according to this text, for instance, or there's a controversy about the name that you can see in this article for all sorts of data about the data. And then it can also be used for discussions about the data because you can annotate annotations. So if someone makes an annotation, someone can also comment on this annotation, et cetera. And the way we want to use it for access is to allow users to propose some changes to the data through annotations, like for instance, a user could annotate a property of a person, et cetera, saying there's a spelling mistake in the name or this is the wrong name or whatever, or a name should be added. And users could propose that through annotations and then the BDRC staff could have an interface where they could validate or discard the proposed changes. So that's a way to sort of enlarge or allow a user base to interact with the data. So in terms of source code, one important aspect is that due to the semantic nature of our data, we want to make the source code read the semantics of the data of the schema and build the UI and the business rules from the data, from the schema of the data. So in different domains like localization, like in the anthology, you can have the localization of the different properties. Like this property should be displayed as this English string, Chinese string, et cetera. So you will have all the different names of the properties. The data is also semantic as it allows you to have rules about inference. Like if you have this and this information, you can deduce also this information. There's all sorts of inference work in RDF and all, et cetera. So this can be implemented like it's stated in the data, but it's implemented in the source code that will read the data. And access control too. I mean, if you have conventions in your anthology and data, the software just reads how to handle that in the data and play on the business rules. In terms of the code we are building is open source, it's under Apache 2 license. And we only use open source libraries and frameworks that can work on all different OS, like OSX, Windows, Linux, et cetera. We contribute as much as possible to the libraries we use or the frameworks we use. Like for instance, if there's an issue feature, we try to implement it upstream in the framework that we use so that we don't have to write a lot of code, et cetera. And this can be maintained outside our code. And then we try to respect, I mean, what we're trying to do is really build a platform that's production ready. So we are documenting the code, making automatic tests, and making it available on GitHub, having correct dependency management, et cetera, so that it can be used by, I mean, it sort of speaks to other software developers. So it's not just our platform that we are developing for us. And also a nice feature we've added is build automations. Like if there is a software called Begrance, you can download a script that will automatically fetch Linux virtual machine, install all the dependencies of our platform, all the source code, all the data, and serve it on your local computer. And that's the way we ourselves have set up our development platform on our laptops and also on the servers we have. So doing this, you can very easily have a complete platform on your laptop and do some search, et cetera. Very easily. I mean, it's just a matter of launching a script. So you can stay there. So in addition, I think we're pretty good, maybe two minutes. The issue of long-term preservation, all three of these levels, types of data, will preserve long-term. So we go to the next slide, maybe. So Harvard Digital Repository Services are a partner for long-term preservation. And basically what you have is a series of content models that you publish into and then they handle the obsolescence and the digital degradation, the bit rot, and backups and migrations and so forth. All of the page images, archival images, as well as web delivery images, all the metadata and all the source code. So this is important, I think, in a lot of digital humanities projects to have some sense of long-term preservation. I know a lot of funding agencies are now requiring data management plans in grants. So that's it. We have one minute for questions. Like step by step, when did the scale up to this kind of a large dimension? Well, we have maybe six major releases of our Pub Digital Library. So we started in 1999. And then really in 2006, we did a major shift in the architecture with new metadata and a whole web platform that delivered images. So that was one major release. And then in 2009, we implemented full localization of everything using the same metadata format. Now, this project started basically this year. But all of our data before was kind of like RDF ready, but not actually RDF. So now the full move and the semantic web and linked data is now. That's our project now. So yeah. Others, you developed yourself. I was wondering when you choose to develop something yourself. And let's say you're on top of the food on, you need to be on top of the project. When and how is that situated and why? It's just if it doesn't exist anywhere, we implement it. But if it exists somewhere, we really want to use like standard libraries, et cetera, like the. But I think you, on top of it, do exist. Yeah, but not with that level of details we need because one aspect is our core data is in RIA. So we need a way in our technology to describe all the details we need. Current ontology tend to be quite, I don't know, very small and more focused on interoperability. Like on schema.org, you have very few properties. And we could, I mean, we could export our data to schema.org ontology, for instance. But we couldn't export all the details. Like everything, like how the data would be lost in translation. So we need something that can really manage all our details of our data. It's a good question, but it's actually at the heart of semantic web link data is that decision when you use a standard guideline vocabulary, common vocabulary versus when you implement your own. So at least there's a framework for that consideration. Right, yeah. I'm also thinking about the only channel you mentioned about your channel search.exe.  So you should do that. They would try to get a highly, some very different languages, search.exe. Yeah, I mean, it didn't. We need to take a very different approach to that. No, it just, what we are doing is just plug-ins for the scene. It just didn't exist before. There was no Tibetan analyzer for the scene. And so we are just developing one Tibetan plug-in for the scene, and one for Sanskrit, one for Pali, etc. But in a very easy way. Yeah, it didn't exist. That makes sense, yeah. We have to go on, let's go down and talk. Sorry, we have to go on.


Robots, artificial intelligence, and machine learning could be used for nuclear inspections in the future, according to experts meeting in Vienna this week. As the world's nuclear watchdog, the IAEA is responsible for verifying that nuclear material is not diverted from peaceful uses to make nuclear weapons. To do this, hundreds of IAEA inspectors travel around the world to verify how much nuclear material a country has and where it is located. They employ a range of technologies, including special cameras, swipe samples, and radiation detectors. New technologies offer opportunities and present challenges. We need to explore this opportunity if we want to work more effectively and efficiently. This is the only way to stay ahead of the game. To fulfill its mandate, the agency needs to continue to take advantage of the newest technology, according to nuclear inspectors and innovation experts. I think innovation is really important for the agency because the world is changing at a really, really fast rate. And so we need to think about what we're doing, what we're doing really matters so we need to make sure we get it right. IAEA workshops such as this one bring inspectors, member states, NGOs, and the private sector together to find ways that emerging technologies can help deter the spread of nuclear weapons.


The reason why narcissists are always mad, when you are involved with a narcissist, it isn't long until you begin to see their anger, or it may be their anger that makes you aware of them, and this is a recognizable trait in any narcissist.  The reason why narcissists are so angry or upset is because they have less or something different than what they think they deserve, they think that they have been treated unfairly, they think that other people have unfair advantages, narcissists are arrogant and entitled, they have an exaggerated sense of their own abilities and opponents, which leads them to feel inherently deserving of privileges and special treatment, they believe that they should be successful, they believe that they should have money, they believe that they should be with people who are attractive, wealthy and successful, just because they want it, and often without doing anything to earn it, they expect things to fall into their lap, they expect to receive whatever they want, unexpectedly or without effort, because they assume that's how other people manifested what they wanted, because all they see is the finished product, they don't see or care about the hard work that those people put in, to get to where they are today, all they're concerned is what those people have now, narcissists are very competitive, they have a strong desire to be better than other people, which is why they're always making comparisons, but sometimes what they have just doesn't measure up, it doesn't meet a particular requirement, standard or expectation, it's not good enough to compete, and that's when they get mad, they get bitter and resentful, because they feel like they are more deserving than other people, so they feel like it's unfair, when a healthy person would be able to accept that there's always going to be people who have put something more or something greater than them, there's always going to be people who are more successful or more attractive, there's always going to be people who have something better than what you have, but if you're a healthy person, you're not going to let it dictate your feelings and actions, you're not going to let it control you, you're not going to let it change how you feel about yourself, but the narcissist needs people to prop up their false self, they need people to support the illusion, so when they come across people who they see better or greater than them, it affects them greatly, it causes them to feel inadequate, as though they have no value or useful purpose, because they have a dualistic mentality, they see everything in black or white, where something is either all good or all bad, perfect or flawed, which is why they cannot accept their flaws or imperfections, they cannot accept their faults or mistakes, because then that would open the floodgates to everything else they've buried in the past, which would be too much for them to deal with, their anger and resentment is a coping mechanism and a defence mechanism to compensate for how they really see themselves, because deep down they know they're not special, they just don't want to accept it, so instead they act like they're always the victim, they act like everything's unfair, because they can't accept that maybe what they have is what they deserve, maybe what they have is just a result of their own actions and efforts, they don't want to accept that, because to them it would mean that they're not good enough, which is like death to a narcissist, they have to be the best, or they have to have people or circumstances to blame, for why they're not where they think they should be, it can never be their fault, because they can't deal with the shame, but while it may seem like they're mad at you, they're actually just mad at themselves, narcissists hate themselves, which is why they abandoned their true self a long time ago, and constructed a false self that is meant to be perfect, because they just couldn't cope with those feelings of inadequacy, but if there aren't people around to support their false self, it will collapse on top of itself, because it has a weak foundation and structure, it was built on a house of cards, it's just a fantasy, it's a dream, all the narcissists can really do is manipulate you, the best you'll ever get from them is an illusion, they can only sell you the dream, not because they're trying to do something for you, but because your belief has power, your belief is like the batteries for their dream machine, because all the narcissists really want as they never end in dream, they don't ever want to wake up, any time that they start to regain consciousness, it causes a narcissistic injury, because they just can't deal with reality, and whenever they see someone who they think has something better or greater, it pulls them back into reality, it makes them feel like they're under attack, so they have to protect and defend their false self, their narcissism is designed to protect them, from ever accepting or tolerating the truth, that maybe they're not as special or as great as they think they are, whenever it appears that the narcissist is mad, it's because they just reflected on the fact that maybe they're just another drop in the ocean. Thank you for watching, I hope this video resonates with you, please like, comment, share and subscribe, if you would like to donate, my PayPal link is in the video description, coaching inquiries, you can email me at coaching at Narc Survivor at Kudu UK, thank you for watching and I'll talk to you soon.


This section is called convoluted tubules. So who are we going to talk about? The proximal convoluted tubule and the distal convoluted tubule. Now, think for a second. If I'm looking at a slide of kidney, where am I going to see these guys? You're going to see them in the cortex. You're not going to see distal convoluted tubules or proximal convoluted tubules in the medulla of the kidney. How do you know if you're in the cortex? The glomerulus is easy to find. It's about the only thing that is striking the rest of the kidney slide. Literally looks like a bazillion tubes, circles with lumens. And sometimes lumens that don't really look like lumens, and is that a lumen? I don't know if that's a lumen, but if you think about a million nephrons in a kidney, of course it's going to be a bunch of tubes. Like the whole thing is nothing but tubes. That's what a kidney is. So we're looking for some sense of where it, what is all this? We're going to look for glomeruli. I'm going to show you a slide in a second that's going to show you what the glomerulus looks like. And we already know what the glomerulus looks like because we targeted in on that 20 lectures ago when we looked at simple squamous epithelium which is what the parietal layer of Bowman's capsule is made out of. We're going to expect to see distal convoluted tubule and proximal convoluted tubules in the same level of cortex that we see glomeruli. So let's go look at that. Once you're not seeing glomeruli anymore, you know you're in the medulla. And then who are we going to see if we're in the medulla? We're going to see loops of Henley and collecting ducts. So really it's pretty straightforward. The histology, right? Histology's always straightforward. Okay, so let's look at this picture of an actual slide. What do you see? First off, what is this knot of capillaries? This is my glomerulus. Now, you tell me. It doesn't look like the last picture that we just showed you. In fact, the last picture that I just showed you is right here. Can you see what is capillary in the potocyte or visceral layer of Bowman's capsule? Yeah, no. That looks like a mess of messiness. What I know is that there are potocytes there, and I know that there's blood vessels, capillaries there, and there's no way on the planet that I can tell the difference. Maybe somebody can. Holy tubes, what? Look at all these tubes. Just for perspective, are these tubes lined with simple squamous epithelium? Like what kind of epithelium lines these tubes?  Are they flattened and squamous looking? No, they're definitely not squamous looking. These are cuboidal cells. Some of them get a little taller, they kind of maybe lean toward columnar-ish, but for the most part, at least definitely what I'm seeing here, these are cuboidal cells. I see, are you ready for the distinction? I totally see distal convoluted tubule and proximal convoluted tubule. Are you ready to hear the difference? This one is distal convoluted tubule. This one is proximal. Proximal distal. Distal, that looks like proximal up there. What's the difference? Proximal convoluted tubule looks like a mess inside. Distal convoluted tubule looks clean inside. What? How could that be? Are you ready? Proximal convoluted tubule has microvilli on the luminal border. Why? Because 70% of all the filtrate that you filtered out, 70% of your 180 liters gets reabsorbed by the proximal convoluted tubule cells. How do they do it? Physio. Why do they do it? Physio. What are the structures that enable them to do it? Anatomy. They're covered with microvilli to increase surface area so they're more effective at reabsorption. Distal convoluted tubule, it still is reabsorbing stuff and it still is monitoring, not monitoring, modifying. Who's an M word? Modifying the filtrate but not doing nearly the action of the proximal convoluted tubule is. Okay. So can you tell the difference between them? Of course you can. And make sure when you're in lab and you find some, quiz each other. Really, quiz each other. All right, let's look at what the loops of Henley are like.