 Hi Thank you all for coming. This is the first of five status reports from the Drupal 8 initiative leads My name is Greg Dunlap. I'm the Drupal 8 configuration management initiative lead I work an old one in Sweden and I also helped to organize the core conversations this year I don't really we have we have a long Time set aside. I think two and a half total hours to do all of these initiative updates I tried to set a lot of time because I assumed that there was going to be a lot of discussion Around some of them and I wanted to give everyone time to you know, collect up their rocks and stones to throw But it's entirely possible that this won't last the entire time and we might be done early I don't know. We'll just have to see how it goes. So but we've got a lot of time And so if we have questions and stuff at the end of them, please feel free to get them to bring them up Yes, Larry He's asking if we can do all the presentations back to back and then QA I don't really think that's gonna be necessary or efficient necessarily and I don't really have an order in mind either I was just gonna see who happened to make it and then and then call them up next But I think all of us are here right now too. So We'll just have to see how it goes so That's me. I'm Hey rocker on Twitter and on Drupal.org So as some background Last year not last year six months ago in Drupal con Chicago I gave a core conversation called what's wrong with our staging and deployment processes And why were why we're why our approach why our approach to station and deployment is all wrong What really well I was really happy with it And I outlined all sorts of big grand ideas that I had about ways that we could fix this going forward and That that differentiated a little bit in a ways that I thought that other people were doing them And after that Dries approached me and asked me if I would like to run the initiative for that and I said to myself Oh crap Because now I've actually got to do all this stuff. It's easy to stand up here and rant and rave in front of you guys It's actually kind of fun but So I said yes, and so it's a lesson to anybody who has this big idea to do a core conversation and try and get a big Initiative off the off the ground. I would say this So after Dries Asked me to do this and I said yes And I worked it out with my work to get some time to work on it and stuff I started doing some research and looking into how other systems work and how other systems do their deployment problems That posted some of those notes, but what really came out of that is that a lot of the problems we have are unique not because We're the only system with deployment problems But because almost all of the other CMS products on the market have have a much much much stricter line between content Configuration than we do. I don't think this is really, you know, brain rocket science to anybody who's dealt with Drupal for a while I was a little surprised to find that everybody else had really started that way from the beginning as a concept I thought I might find some other systems that were a little more In tune with us, but I really didn't so when I started Putting together is what I thought would be a workable battle plan for getting this stuff going So I wrote that up and published it and if you want to see it. It's at that it's at that URL What it really outlined was two main two main Tax that we are gonna approach and one was Doing a standardized file based configuration system that went over here And then doing getting new UIDs in the core and improving the NED API over here So that we could do content staging and we still had this problem of content and configuration And so what I proposed was that anything that's an entity should be considered content and anything that's not should be considered configuration this wasn't really a Idea that I put forth because I believed in it because I actually believed that a Separating content configuration is sort of an impossible task at this point And a lot of the strengths of Drupal come from the fact that they're so tightly melded together But on the other hand I realized that This is new and it's a learning experience and that actually doing it this way would teach us a lot about our content and our configuration and if we ever wanted to go with a more unified system down the road What we learned from doing this and from where our differences and similarities lie Would be would be really helpful Since then there have been a lot of talks about moving entities into things that we would probably consider Configuration like menu items and content types and stuff like this. So I consider this an involving discussion basically But I don't think that necessarily for a lot of our use cases it affects a lot of what we're doing going forward But it's worth continuing to talk and think about and it's an important question So the first pass at this was starting to talk about centralized configuration a lot of this was Initiated and based on a core conversation that David Strauss gave in Chicago last year where he proposed that all of our configuration should be done on the file system solely on the file system Basically what you did in the UI would write to files that lived on the file system We wouldn't have any database access at all for them and that those files should be stored in a standardized human readable format like Jason We had a code sprint in Denver. That's Larry Garfield me checks Angie and David at the Aitton design lab offices in Denver and We sat there and hacked away at things for about four days They came up with this idea of doing things in files But also storing them in the database at the same time. So you have kind of a two storage system The files would be canonical and the database storage would be the stuff that you access most often It allows us to sort of do One of the things that we were concerned about was the security because before doing Jason files they're readable by anybody who can browse the inner who can browse to the directory and knows the name of the files and so And and but that file directory also has to be world-rightable so that the Apache can write to it and so we were really concerned about the security of that and we came up with some ideas around that and This two-stage system was also part of that because we were going to key the files And if you could and if you saw that the key was busted that the key was wrong and your data Had changed out from underneath you you still had this database storage that you could fall back on it meant your site Didn't die if your files were messed up, which we thought was important. I had some other benefits, too, but So at the end of that At the end of and this would also be designed to replace what is our variable system now and probably parts Or at least some use cases for the system table and some other things and after that was over I posted a Angie posted actually we wrote it together a big outline of our proposal for What we were going to do with this and we linked to the to the sandbox where he had written our prototype code and Then we opened it up for comments and wow, did you guys deliver? So a lot of good things came out of that discussion We improved the security model I think We changed some of the ways that we were going to store the files because originally to secure them We had kind of we were kind of gonna make this bastardized Jason dot PHP format so that they would still be Jason But they'd be executable so you couldn't read them and blah blah that was an extremely unpopular proposal So we came up with some other alternatives around that and worked with the security team to figure that out And we also started a very very very long discussion about the file formats and what the file format should be And should they be Jason and should they be any files? Should they be XML blah blah blah went back and forth and back and forth for a long time and Finally I posted a thing about two weeks ago where I said I'm gonna say we should just use XML And you give me a good reason not to but if I don't get a good reason not to this is what we're gonna do And I haven't gotten any good reasons not to so I'm gonna say right now. This is what we're gonna do It's I think it's I think it's I think it's really important that we Do that and that we take the API and that we don't bake the a don't bake XML into the API We should make the XML as agnostic to the file format as possible because we may end up digging ourselves into a hole with the file format Or making it pluggable later and stuff like that But I think it's really important to make these decisions and move on and one of the things that I haven't really done I think as well as I could in this initiative is time boxing things and saying we're gonna talk about this for a Week and then we're gonna move on and a lot of this stuff has dragged on for a while and I was on vacation in the States for For you know, I've been I've been I think out of the last three months. I've been traveling two and a half of them So, you know, that hasn't helped anything and stuff either so Another thing that came out of a lot of those discussions is that we kind of decided that You know storing storing the files and making the files canonical is is If we could avoid that whole problem if we didn't store the files all the time at all because you know A lot of what our discussions were about was the security issues of having these files sitting on disk And we were going around around around around about this and then somebody I don't remember who it might have been checks Suggested that if we don't store the files all the time at all I mean, we're using the seconds the database store almost all the time when we access stuff The only reason we need the files is for if you happen to need to edit one by hand to do overrides or something like that or If you're pushing your deployment, so why don't we turn it into the database store is the main thing and and it becomes an Deployments become an export and import operation essentially There was a lot of pop. I wasn't a big fan of that, but it was very popular And so I think we're going I think we decided that we're going to do that. It hasn't been written But that was another change that came out of the discussions from the community after our original proposal Did I miss anything there Larry? Yeah, the summary of three long months of our lives So that's sort of where the file-based configuration stuff stands right now I think we need to get back to the I think it's really important that we get back to coding and prototyping After all this talking and discussing I don't want to get into any more analysis paralysis on this at this point And maybe we'll start talking about next steps about that at the code sprint on Friday So that was the first sort of three prongs of my initiative the second prong was actually Originally, there was a the second prong was that I wanted to get you you IDs worked into core and I wanted to implement them throughout our entity system and Peter Willanen came up to me and said It's really dumb for you to do this because we're going to be reworking the entity system Anyways, and then you should be a waste of time You're just gonna end up throwing all that code away and I'm like well Who's redoing the entity system somebody is somebody actually doing it? I've heard a lot of talk and he's like well I want to do it and I'm like well Why don't you come in here and do it with me and then we can turn it into? Part of the initiative because I need it and you know, it's it's something I want to see happen anyways And he said okay, so reworking the entity API Got moved under the auspices of my initiative as it were I don't really know what that means other than me saying I need this and giving them access to my sandbox to work, but Peter and Fago and catch have been working on that mostly Their main first task is to move the stuff in any I think into a proper module and then to build a crud API Hello Cleveland So and then building a proper crud API on top of it, which we don't really have I think that's really important It enables a lot of a lot of it opens the way for us to do a lot of stuff with entities even outside of my initiative And it will it will give us it will give us a pathway towards proper content import export for maybe the first time in our entire lives If anybody saw Damien's core conversation about document oriented storage yesterday It would it would start opening up a pathway for us to build that underneath entities So outside of my initiative or anything. It's this is good thing And so Peter and Fago are having a core conversation tomorrow at 11 about this if anybody wants to come This first link here is a pointer to the issue that they have in the queue about moving entities Onto a module. What's the status of that issue right now? needs review so Get on it people And then that second link is Linked to notes from a bof that they ran about entities in the path forward for entities at Drupal con Chicago If anybody's really interested in the ideas that other people have about what where the entity should go forward So the last part of this is the content staging thing in some ways, this is the Easiest part of it because nobody cares about this but me And so I can just do all this work and nobody hassles me about it, which is great but The basic plan for this is that Whenever there are two really big problems that we have with content staging right now one is that because we're using Because we're using the serialized IDs and the auto ink IDs in the databases We have no control over what they are and they shift from server to server And so it's impossible uniquely identify content The second problem is that the way that Drupal's APIs are now especially the way that they're so tied into form API It's extremely difficult to save to save nodes or any other content in a reasonable way and entities We're a step forward with that but because the API never really got finished. It's still not really there for Drupal 7 and so My idea for contents for content staging was if we get you IDs and a proper entity API Then even if we don't build any content staging into Drupal itself We've we've got a big win and if that falls out to contribute for Drupal 8 and we never do anything more with that I think I'm pretty happy actually so The first patch for you you IDs in core is in is in the queue right now It was written by Dick Olson who's working right now in Qatar for Al Jazeera And it's really just an API patch. It just introduces a bunch of functions that will need to do you IDs in core The next steps in that will be that once the entity API stuff is finished that we start working the generation and saving and retrieval of those UU IDs into the API and then And then we decide what we're gonna do with it Which is a whole another question needs to talk about use cases and user stories and do we how much of this do We want to bake into Drupal as a release and how much do we want to leave to contribute and stuff like that Which is a discussion. We haven't even started but My outline for getting all of this done and my steps and plan for it. Is it that node right there? And so that's really where that aspect of the initiative is at at this point so What are some problems that we've had as we've been moving forward? Discussions are hard and so one of one of the problems with the discussions that we've been having and we've talked About it a lot among the initiative owners is that our tools for having discussions on Drupal.org Infrastructure are really really poor. We have Issue queues which some people say is where all the discussions should happen But anybody who's followed a long meta issue in the issue queues knows how horrifying that is It's really good for jumping to the end and seeing what the most recent comments are and stuff But it's really hard to follow the context of a conversation through it on the other hand We have GDO which is good in some ways also But some people hate threaded comments and it's really hard to in both of these cases To kind of tie a bunch of topics together for instance when we made our first blog post about the overarching Proposal we had I got 400 comments and I'm like oh this is too much And so I start breaking out into sub topics and sub discussions But then what would happen is people would jump into those sub discussions without any of the overarching context that we Provided in the first post and they're making these comments where they don't understand what we're getting into and what our priorities are and stuff like this And I don't have a really good answer for how to manage that at this point I think it'll be easier when we get to coding because that's the way that we're all used to working and we're all used to working in the issue queues and You know in the past even when we've done big architectural changes I don't think we've really tried to open them up to community inputs so much as I'm trying to do here I think it's really important you know a lot of people Complained that when the field API was designed that it was kind of five guys in a smoke filled room And they came out with this proposal and anyone who didn't give a proposal and anyone who didn't agree was kind of like well That's too bad. That's what we decided Yeah, it didn't really happen that way But that was the impression that people had and so I was really focused and I made clear to trees that I didn't want Anybody to come out of this process feeling that way of course now I'm feeling that the pain and kind of and you know kind of like why don't we all just go off in a smoke filled room and figure this out So I think I still think it's really important But I need to figure out a way to have these discussions to have the context and to Get everything together and keep them focused in all of this and it's really and it's and I'm still trying to figure that out And it's hard for me because I live across the sea from where almost everybody who's commenting on these issues live And and it's nice that I have people like Larry and David to keep a track on them on North American time and stuff like that But still that's something. I'm still trying to sort out I mean one thing that's really important that I haven't been doing is I haven't been time-boxing the discussions very well So they just sort of go on and on and on and on and you know I think I think it's really important to open them up to more of like a We're gonna discuss this for a week and then we're gonna make a decision and then we're gonna move forward And that leads to sort of that I need to be quicker on the trigger about decisions and you know and push things forward This is a really new kind of role for me and You know even when I've done core development in the past. It's been really kind of High-impact easy-win stuff a lot of documentation API changes and easy bugs and stuff like that So my experience with the core development and the teams isn't the same as a lot of other peoples And I don't have a lot of this You know cat-herding experience and so I'm trying to grow into this too And I think I think things will be better going forward and I credit web chick a lot for helping me out And I've been really appreciative of that So next steps We need to code we need to start coding. I think that's really important. I think that's what people in the core Development team want to see they want to see actual stuff happening And so I think it's really important that we start doing that So my first step will be to start updating our sandbox code from the code sprint with the results of the discussions that we had on GDO and then Once we've done that we can start once that API is finished and everybody's happy with it We can start actually going in and starting to replace some of the stuff from variables tables trying to see if we can implement Field configuration with this system trying to rewrite system settings form to use it and things like that And I think that'll really teach us a lot is when we start getting into those implementations We need to keep forward moving forward on the UID and entity work and that's still happening and That's and that's all good and we just need to keep talking and pushing forward We need to talk and push forward both we can't just talk and we can't just go there's a right balance We really need to find and I don't think we found it yet, but I think it's important to keep figure trying to figure that out This is not the same slide And that's all I've got to say and now I will open the floor to questions from the audience Yes, Jennifer the question is are you planning on having the revisions as well as the base entities have you UIDs? I've seen some of the discussions around that and I haven't really thought it through myself, but my initial My initial responses, I think that's probably a good idea though so But I mean obviously So I'm thinking about the help system that we're thinking about for Drupal 8 hopefully where we would be probably importing Help documents from a centralized help server or maybe multiple centralized help server and you could conceivably Revise it on your own site and then want to know whether you should pull in the next revision from the other site And you kind of want to have a UID on the revision so you can tell where you are in the revision cycle or something like that All right You know I mean you know the more I think about it the harder I find it to believe that we wouldn't put you UIDs on revisions, but I mean it's something we have to talk through too Yes The question was wouldn't it be better to store the UIDs in the database as binary instead of text I Would have to think about the pros and cons of that I suspect Larry has an opinion about that Which were not by the way, I didn't mention that here But we're not we're not planning on we're planning on keeping the auto increment primary keys The UIDs will just lay next to them because the process of converting to UID primary keys has a Men's performance impact and as as an upgrade path thing. Oh my god. It makes me want to shoot myself So I mean that's that's our plan. So anyways Yes, please Anybody else Really man I Expected lots of rocks. All right. Well, thanks Which of the initiative owners Larry? Okay, I think we can get started So this is update number two. This is for the web services and context core initiative one of the more of her boastly named initiatives we have I'm Larry Garfield or Krill senior architect with Palancy dot net various other things I'm not listening here and Really mean with a Nerf gun and can record over here can verify that So We're talking about the web services and context core initiative or whiskey So names because I like funny acronyms. I that's how you know. I'm an open-source geek So bit of backgrounds back in 2009 during an online Chat with Lisa Reichelt Earl Miles made the comment that Drupal doesn't have multiple layouts It has one layout that it bends a lot and It's really unfortunate that he said that because it got me thinking and that's never a good thing Thinking okay, just what could we do to give Drupal multiple layouts and nothing else, you know make life easier for designers and I thought this through and then came up with a presentation at the Developer summit at Drupal Con San Francisco. It's like the precursor of the core conversations in which I basically laid out This is what our page layout system looks like now you have main content area and then these block regions on the side and these blocks that know nothing about anything and if you want to do anything that doesn't look like this you're kind of screwed and You know your options are hack the template to plea to pieces or use panels and What we really want to do on the front end is something that looks more like this Where you have requests come in we build up some more intelligent metadata based on that That's we call context is in the more robust definition of the request pass that to a display controller which then gets rendered into this one big Region inside of which are regions inside of which are regions inside of which are blocks and You just keep passing this information down The idea here is each of these blocks can be rendered independently of each other You can lay them out independently of each other. You can have complex layouts like this You can change the context information at this point going from one layer to the next and Basically if any of you are looking at this and saying wow this looks familiar that's because this is pretty much the conceptual logic behind panels You know arrived at it by a different path, but it's essentially the same concept and We identified Five basic things in Drupal that make it impossible to do this in core right now The fact that we have no unified context system we have you know a half dozen correction several dozen Different functions that work differently in some globals that you can't really override without breaking things We only have the ability to support one layout. There's no way to define multiple layouts We have no good system for defining swappable components. We have a one-off thing for blocks that sucks We have a one-off thing for page callbacks, which sucks We have a one-off thing for input formats or text filters, which sucks continue on down the line The entire system assumes you're returning an HTML page and even just returning HTML fragment requires Essentially hacking around the menu system And of course your performance is a problem because of how much work we're doing as a result of all of this So this gave birth in San Francisco to the Butler project Which was basically in order to solve this layout problem. We have to solve all of these other problems first Overall idea is to give Drupal a unified powerful context system that supports smarter block-centric layouts using a common plug-in mechanism. It's a mouthful and a lot of discussion happened on this summer of last year that kind of focused into a Presentation I gave it at Drupal con Copenhagen, which unfortunately was not recorded because of a technical glitch but that's basically, you know refining this idea and Then was refined a bit more And say some code is written by Drupal con Chicago Where I gave a essentially an earlier version of this talk at the core conversation track there And then Dries came up and said hey Larry this sounds like it'd be useful for web services You want to lead a core initiative and much like Greg. I'm like yes crap Yeah, congratulations, that's that's how everything core works So The basic idea of the web service initiative is more or less the same thing Which is we want to transform Drupal from being a CMS into a rest server That happens to have a damn good CMS on top of it and To do that we have to do all of the stuff Butler was talking about so it part of the challenge with Drupal right now is that Making our layout system not suck requires Rewramp or rewriting our routing mechanism to be a rest router because those overlap so much in core that we can't do one without the other So let's just solve both problems In particular, you know break it up into four pieces because that's a big mouthful. We want unified powerful context system So that all incoming information we access through a single channel we get rid of our globals We get rid of dollar underscore get dollar post All of this information we handle in a consistent fashion and We can then use that to build a really powerful in core plug-in system Make more things swappable in the same way rather than making them swappable in a different way for every single system we run across With those two tools we can then build a much better router in core Essentially a replacement for hook menu that can deal with the fact that not everything is an HTTP get request for a full HTML page For a desktop browser within three years that will be the minority of traffic on the web Let that sink in within three years Requesting a full HTML page for a desktop browser will be a minority of the web and then You know build these smart block-centric panels like layouts That give us real a great deal more flexibility on the design level More flexibility in terms of caching pages for better for performance because we can partially cache based on the blocks You know replace the entire stack there because we can't change one part of without changing the others so since Chicago there's been a ton of discussion and Basically everything Greg just said about the challenges of doing architecture in the open like that apply here, too So what he said? There have been a lot of very long threads that suck your soul, but needs to happen anyway But we do have a viable plan moving forward at this point that we are starting to work on step zero Geeks like to start at zero is an actual way of handling HTTP right now We're way of handling an incoming HTTP request is Global dollar get which we overwrite portions of before Drupal even finishes booting up, which is already doing something bad We kind of wrap dollar posts in the form system But only in the form system if you're doing non-form stuff with posts then you kind of are on your own and Any information that you derive off of that? Even like what type of request this is do you does the browser wants JavaScript back does it wants HTML back? We have no common way of tracking that So rather than write our own complete wrapper layer for incoming HTTP requests. There are lots of them out there so we first spent some time looking at the peckle module for HTTP handling and Basically came to the conclusion. We can't require that to be installed on the server Porting it to user space would be way too much work and probably wouldn't work anyway. So let's not do that so then we started saying okay need to find a good third-party library here and Dave Hall and Dick Olson are either of you here Okay, they did some excellent What's that? Okay, well, I know dicks are on here somewhere, but they did some really great research for us Looking at the HTTP libraries inside the Zen framework and inside symphony to which are two of the largest component frameworks very modern freshly rewritten So they've done an awful lot of work that we then we don't have to do and say okay Can we piggyback off of them in a good open-source fashion and their research is posted here these slides will be online, so you don't need to write that down and Contrary to all of the threads that came before it the conclusion that pretty much everyone in thread drew was symphony So we want to use the symphony to HTTP library for handling incoming requests, and that's our level zero so hopefully this is the start of you know our projects working together more I Let you decide which is the mouse which is the cat Mostly I just wanted an excuse to use this slide And As of last night at 2 a.m. Dries told me that he's okay with doing this So I'm gonna be writing the patch for this very soon to just drop in portions of symphony to into Drupal core for Drupal 8 Now my hope is that Dries was awake enough at 2 a.m. To remember that he said this Yes, Jen Yeah Yeah, the question is is this the first time we've done this no there have been other examples But it's not something we do often So it is a major event, but the fact that we got it approved yesterday. It means we can move forward with that Then step one is a unified context system this where most of the work has been done We actually developed an API for the most part back in Copenhagen. So that's now a year ago It's based on the on a mediator object that a butler object essentially the idea being that When you want information about the request which includes information that derives from the request like what's the current node being? Requested you don't check that directly you instead ask this Common broker, okay, what is the current node and it will tell you Or it can lie to you if you want to you know do fancy caching you can encapsulate Your plug-in your block your whatever very well that makes it unit testable that makes it easy to Cache it independently of the rest of the page. It means you can do an aha request You can do ESI caching all kinds of fun stuff basic idea You know some piece of code asks this butler objects this context object, you know What is the value of this HTTP property? What is the currently active node? What is the current user so global user goes away and gets replaced with you know some handler that just returns That context information that you can use Work in progress on this is in a Project currently this is a Drupal 7 project, but it's not like there's a difference between between that and Drupal 8 at the Moment and hopefully by the end of the week I'll have this in a sandbox a core sandbox basic API if You have a class then You get a context object passed into you and you just save that when you want to say what's my current? You know, what's the current node you? access it that way What's you know the value of this get variable use this colon to limited format which means we can assign a single handler right here and then You know one context handler that handles all of those requests and this is the only way that you access this information You do not ever touch dollar get directly. You do not ever touch global user. It goes away. You do not ever touch Global language that goes away Everything is accessed through this context object if you're in procedural code Then you have this Drupal get context function that gets you the top most object context object You can register you a new handler this way so when you get this request, this is the class that handles it Here's some configuration information. I'm just gonna blitz past this One important factor it is over writable So you can say okay, you know this I've got this object add a new layer And I've got a new context object. I'm going to set some additional configuration on that Lock it and then pass that along So now this code here or whatever is happening inside there Does not know anything about this object. All it knows is your overridden form here This is a very good thing because it allows you to Segment parts of the system it allows you to pull pieces apart by going through this mediator in between We can unit test things we can You know like I said I was saying before we can ESI cache this way because you can fake this out very very easily Current status in that there's one patch left that I want to get committed before we can start implementing it in core to see what happens I'm gonna try and get that committed tonight. I need to review it to actually have two possible implementations of that my my plan is if I can get that in and get a sandbox going by Friday then Come on Friday. We can just start implementing this in core see how far we can get replacing global user see how far we can get replacing global language and and figure out if there's problems there where the gaps still are and Hopefully get something going that we can have trees push back into core and get really get rolling in Drupal 8 At least that's the plan. So who's gonna come on Friday and help with that? Awesome. I'll see you there Phase 2 plugins Yeah, we've got way too many of them let's unify this crap Basic logic. We're looking at here You know you have a plug-in type You have various plugins that's conformed to that type and then when you want to use it you have some configuration and Some context the current context object combine those you get a plug-in object and you can then just use that and This works for all kinds of things This like the canonical example would be the cache system So you've got cache interface and actual PHP interface language construct different possible implementations of it you have configuration and Then you just go use that object cache In performance sessions You know all kinds of things Entity backends Entity storage backends. I've been talking to if Shed and why he really wants to use the system to clean up the API for Formatters and widgets and fields in Drupal. So all of these things. Hopefully we can get working on the same Interf the same architecture We all did some research here as well we looked at symphony twos plug-in framework Zen frameworks and kohanas and Basic conclusion was none of them were doing anything even close to the level of complexity we needed In fact, the closest system conceptually is our own C tools module. So thank you C tools team So the current plan there is essentially a cleaned up purely object oriented version of C tools plugins That we slide into core There's actually two different implementations right now that we put together just kind of as experimental work one I wrote a while back one Nick Lindell has been working on and Honestly, they're about 80% the same thing give or take some terminology there. They're very very close I don't have the sandbox URLs off available off the top of my head. Unfortunately But we're sitting on that for the moment and we come back to it after we get the context in course We can really get rolling with that, but I'm hoping that we can just build off of one of those two approaches and just roll with that and Once we have that built Then we can start the fun stuff which is using these plugins and this context information to do real web server routing to actually use HTTP properly unlike most PHP frameworks current plan based on a conversation we had here is A two-layer approach. So currently request comes in all we match it against is the path and that's it And we pass it off to a function Instead we match it against as much information out of the HTTP request itself as we can Which is the method? I forgot a comma comma there the path Domain and the content type That is like this is a get request or a post request or a delete request to this domain or to any domain this path and The browser is requesting type slash text slash Jason or text HTML or application PDF and we can then return a true HTTP 200 request or A true 404 rather than hacking our way around it or a true You know moved there's a ton of information in HTTP in that spec that we're not using that if we really want to be serious about web Services, we really want to be serious about mobile. We have to use This lets us handle all of that stuff in a clean fashion rather than just hacking around a page system Again lots more detail here Encourage you look at that Oh, yeah, and other stuff like node type is a Secondary layer that we haven't figured out the details on yet. Yes, Peter Because you we want That routed to be swappable. We also want what this is going to map to is a Configured plug-in object that is that display controller and this is again very similar to the way panels works conceptually Where you know what you get back from here is not name of function It's a name of an object or class and configuration and That's plug-in based so it's used that same consistent API is everything else Architecture wise we're already starting to work on this, you know if you want to help with this This is probably the best place to join in the discussion right now But a lot of it is we're going to need some of this functionality anyway So mine as well again use a single system for it Answer your question portions of it we might be able to Yes, some parts possibly we definitely need the context part for it since that's where we'd be getting this information Yeah, I at the moment, I'm not sure yet how much of this system is going to technically be a plug-in That's a good conversation. We still need to have so let's start a thread on that one Actually check this group. We actually do have some discussion there at the moment But that's an open question frankly So parts of this made not need plugins. You're right and finally I get onto the smart block layout Which is essentially? Panels in core so number three is services in core step four is panels in core At the you know 50,000 foot level anyway So far we've not done a great deal here yet because there's a lot of work left to do other than try and figure out Okay, the biggest problem with panels is that the UI is way too complicated for mere mortals to use People in here can figure it out, but most people can't wrap their head around it. So we're trying to figure out So for the record Sam Boyer can figure it out, but I did say mere mortals So yeah, we're trying to figure out what a better UI would be for a Layout mechanism that is all panels based That people can actually understand and so By on and your Roy have been helping out there to figure out. Okay. Let's think this thing through There's a lot of work to be done here So if you're interested in you eggs if you're interested in figuring out how to make a UI for all of this stuff that doesn't suck Talk to me talk to boy and talk to your Roy is your right here? Yeah, your Roy is not here. So talk to either boy on or I I joined in this group is a lot of discussion there And you know, this is still a ways away in terms of implementation, but we're gonna need that long to figure out the UI Because we have to get that right So next steps at this point Friday code sprint. Let's try and get some forward motion on context so we can You know jumpstart the actual code writing If you want to follow the discussions we're having that's groups at triple org slash whiskey wscci If you just want to keep tabs on what's going on there is a tracking issue On Drupal at org is the need for it We're not discussing anything there It's just status updates if you want to get pinged when something major happens I'll be posting comments there. Otherwise almost everything in that thread is us is someone saying subscribe So feel free to add more. I'm encouraging people to say plus one subscribe on that issue and that issue alone And that's it questions no one has any questions There's a question the question is if the router is always mapping to a Response object does that mean that every module has to have OO code and therefore more complex two answers to that one First half. I'm not sure yet if that means that every page callback turns into a new class It may be that there's still a function And there's a common in a class for the configuration is subcalled to this other function for the body We don't know yet. That's still a very open question To the second question, you know it does you know that means it has a class in it and therefore it's more complex Something having a class in it does not make it inherently more complex half the time. It makes it ten times simpler Other questions. Yeah use use what? Okay, can I So the question is Does you can basically this on HTTP make it harder to do command line stuff like drush actually know Because if all Drupal code is accessing that HTTP information through this context object Then it becomes trivial for drush to have its own context object that mocks all of that information That's relevant or has its own information. So everything we're doing here is viable for drush and Hopefully drush can actually simplify a great deal by building off of that same very low level It's kind of in an ideal pony corn world drush and Drupal and the Drupal installer and the Drupal updater are through our all Different applications built on top of this core framework. I don't want to actually get to that point But that's kind of the mystic goal that we're trying to push towards conceptually Other questions All right, then I'll see you all on Friday and stick around for who's next Gabber Stick around for Gabber who's gonna be talking about Internationalization and what we're doing in Drupal 8 for that. So this is my update from the Drupal 8 multilingual initiative I'm a Gabber Hoichi and I was relatively recently named an initiative lead for this project after Larry and Greg and The way I wanted to start this is to look at what What's really the goal of what we want to support in Drupal and The the most basic basic thing where a language comes into play in Drupal is if you want to build a foreign language site So as long as you want to do an English language site as it is intended by the Drupal developers with the original English text You don't need to care about language if you want to do a foreign language site Which can be an English language site with different text in English, but with like different wording Then this is the foreign language site that you want to build and what we need to have there is we need to know the language You're building the site in so we have language information on what you're actually working with and Because the built-in code in Drupal is is all in English We also need to support translating that built-in code built in UI to a different language if that different language is just like Different wording in English. It's from our perspective is still a different language So that's that's about it for a foreign language site, okay So if you want to build like a German site and you and it's purely German, there's nothing else in there Everything's in German then we need to know it's in German and we need to let you translate everything in the code That was in English to German and all the rest of the site the views the menus the blocks everything you built in So you can put in German. There's no need to To to do anything with that. It's a single foreign language site But when multiple languages come into play, there's other things to consider So we need to expand the set of languages we support so now we have multiple languages Which means we need to be able to select from them We need to be able to to know in this Request which language we use or in this part of the request which language we use and that ties in a lot with the context initiative we have there and also That's kind of an interesting way anyway so we We need to we need to know which language we have and we need to be able to select from that language and In Drupal 7 we have multiple types of languages. I'm not sure you're aware, but we have content language We have user interface language and we have URL language and these can be three different languages in Drupal 7 Not many people know that but that is how it is And that's a multilingual site So if you have a multilingual site that is a blog and you post in German and you post in English And you never translate to another language then you don't need to have translation support You just need to have you just need to label your stuff with different languages Okay, so we need to know which part of your site is in which language, but we don't care about Translating all those if you need translation, so you need to actually relate different things together then Translation comes into play. So in that case we need to relate different data objects together based on Their relation through the language. So this is a relation problem. We have different Data elements and we need to relate them based on they are the translation of the same thing So that is the concept there. So those are the main things that we need to care about We need to know the language of everything We need to let you translate the UI We need to be able to select from available data based on your criteria And we need to be able to support translation on a fully multilingual site with translation So we don't have a lot of that in core. Unfortunately. What we have is we have Languages we have UI translation. We have no language support in Drupal 6 with no translation We have support for path. We have support for path aliases kind of interestingly and we have a very Very broken system for configuration translation and we'll talk a little bit about that later in Drupal 7 So this was added on with field translation With date format language support and with comment language support Now you might notice when you actually build Drupal websites These are just like the very very basic pieces that you work for, right? So there's a lot of things you build on websites that don't have any language support So we have blocks. We have menus You have all kinds of configuration like views your site name your rules your panels your everything And I just hold above before this session on multilingual problem sharing and use case discussions and We've had like an interesting question how you translate a panel and the answer was you kind of use a view because that supports translation better and you use views to provide the data for the panel pains and you know, so So one of the problems is we don't have any language information of that and the second problem is you don't have any Translation support for that in core So internationalization model tries to plug in these holes by trying to provide some language information trying to provide some translation support But the the most important problem is that therefore a lot of things we don't know the language So when you start off with a site you put in the site name you create three views And we don't know the language those were created in if you change the site language. It's going to break And we don't have any language based selection and displays is one of the most Requested things it's like I've I've installed this site I've I've I did content translation and my homepage is showing every language. They're like, yes That's how it works. There's no selection there. So let's see content. There's a that's the most important part I I made a like a 20 minute video of this. I'm trying to do a very short some summary of that here So I apologize for anybody who's who've seen this, but I think anybody Remember seeing this Video that I put up with these images Not a lot of people. Okay, so So just so you know the the what what what what what's our way for a content translation is the most important part in my initiative So we have triple six with locale support Which means that when you have a node with all their properties What we do is that we tack on language information in the notes So we know it's in German it's in English. It's in French and we have content translation Which means that we have that node with language information and we relate other nodes In other languages to that node and for this relation set We call it a translation set and we say this these three nodes are translations of the same thing and we Kind of have a source node there. That is the source Data and there's those translations of that node. So we have a translation set of nodes Okay, that was in double six with content translation. That's a very good model for a lot of reasons So for example, you want you have this node and you have copies for this node for translation So you have different copies of the nodes for For these nodes all of those nodes can have different authors So all of those nodes can have different permissions in a workflow setting if you run with Workbench model you can put in those nodes into different cues for different people and Then you can you can work with like these single single objects and the permissions are handled separately the Attributions handle separately. They have different status fields. You can have different workflow in the European Union There's a requirement to post When you like posting official documents, they need to be available in certain set of languages and and until the All those are available. They shouldn't be posted So you set up a workflow you're waiting for all those languages to be available before they are posted They can have different status then the rest of the languages which are still waiting to be translated and are not required For the initial post These have separate menu items So if you want to have language dependent menus like different menu trees for different languages, then you can do this Okay, so it's a very good model for these reasons the problem Is that you have these different copies of the nodes and there's a lot of things that relate to nodes like sign-ups like organi group memberships like votes Five-star whatever so a lot of things relate to nodes and they say I vote for this node Or I'm a member of this node or I sign up for this node or I buy this node and if we have a translation set The module that implements group membership or sign up or votes They need to be aware of you either becoming a member of a node or a translation set and that's not actually happening in fact, there's also fields which Which carry a lot of data or or can be painful to be Duplicated in these different copies so the problem is that you have your source node and different copies of the node And if you have an image filled like a product node like on a product node Then those need to be duplicated or if you have a product price those need to be duplicated So this is kind of a problem so triple seven introduced field translation We'd solve this issue by putting translation under the node Okay, so they put in the different they put in translation for fields so you can keep the price field and the image field as Undetermined undetermined language and you can translate the body your custom field your title Of course title didn't actually happen. Unfortunately He was removed so jubicorps nature is that sometimes stuff get added and they get removed That's how it went. So title is not a field. It's not possible to translate it this way But a lot of the other things are So this is very good because The body field is right there in core you can translate it and there's all kinds of stuff You can do you can add the custom field you can add an image field. It's not translatable, etc so you can decide on the field by field basis on what you want to translate and You don't need to copy that data elsewhere And what's also very good is that all those all those relations will work Because your signups will just work with the node your organic group will just work with the entity with the Five-star will just work with the entity so everything will work nice. Okay, so this is very good however There's all these problems with the same things Like what if you want to actually store votes per language like you're interested in whether the English audience voted for this better or the French That's kind of not in there unless they know the language under the node same thing goes for author It's not a field. So you cannot make it translatable It goes with with the permission associated with the author. You cannot make the different translations Be available under different permissions because it's not a field. It's not translatable It has one author and they have the permission same goes for status same goes for menu item relations So all the things that are not fields now are a problem because Because you cannot make them translatable. So we have these two models and We both we have both of them in Drupal 7. Okay, so we have the node relation model it's an implemented in the country translation model and the field translation model as well and In both cases, there's a problem of you need to relate to either a node or a translation set where node and and language under there In the first case shared that is implicated in the other case the Under the node kind of structure is not well known. So So there's all these problems we face But the main problem really with this model is that you have two models Okay, so if you are the five-star maintainer Your main problem is okay I'm a five-star maintainer and I want to solve that I want to have voting for for multilingual sites So the voting can either happen for a node or a voting can happen for a node in the translation set Or the whole translation set or a language under a node Okay, so Like a module maintainer who wants to support multilingual needs to understand two models of translation and they don't understand either It's not a specific comment for a five-star maintainer It's it's a comment for a lot of module maintainers And why would they need to understand it right if we can design a system where by default it will work for them We could eliminate this problem that they need to understand all the guts of the system to work with them So the possible fix that we come up and came up with but we don't have any concrete solutions for that yet is that is that we Make stuff Fields so body we already solved. Okay, so body is a field that's done that there's nothing to do there For title it would be in ours in our system. It would be ideal to make it a field Like it was It was pulled out for a developer experience and performance reasons There's a lot of work to do in Phil translation to improve developer experience. So we're looking forward to working on that and the most interesting part is Making properties Translatable so you can say this author in this language or that menu item in that language or that status in that language and and Here actually status is like a real property and author and menu item are just relations to outside things So those are basically a special case of a relation of this entity to something else And of course, there's the general thing of likes and votes and all the other kind of relations outside the node so This is basically This is basically the ideal that will that where we can go to and the and the best part is for the default use case it's going to work for all the relations for You