 Yeah? Hey, look at that. Um, okay, so this is, uh, Drupal's future. Uh, I'm gonna be talking a bit about PHP Renaissance, how it affects Drupal, um, and what I think the future is. Uh, if you're not here for this talk, please stay. Uh, very quickly, a little bit about myself. In case you don't know me, I'm Chris Vanderwater. I'm actually the developer over at, um, Aquia. Uh, if you'd like to follow me on Twitter, it's at EclipseGC. Uh, a couple of quick things I've done in the Drupal community that are of note. I'm the scotch initiative owner, I'm the co-maintainer for, uh, Chaos Tools, and, uh, maintain a couple of my own modules, perhaps the most well-known of which is context-administration, and I bet none of you know it. So, moving right along. Uh, let's talk about a number of things. I'm kind of, uh, tell you what I'm gonna tell you, tell you and then tell you what I told you as sort of guy. So we're gonna spend a little bit of this talk, actually digging through Drupal history. Uh, we'll look at some various things that happened over the course of certain commits. We'll look at PHP around the same time, um, and then we're gonna dig into what PHP is doing currently. Uh, talk about Drupal's present and also what I think Drupal's future is or should be. So very quickly, uh, some Drupal history. Uh, at some point in time, there was an introduction of modules, but this was not true, uh, in the beginning, and for purposes of our conversation today, uh, the beginning is actually Thursday, May 18, 2000, which is the initial commit of Drupal 3.0.x. Um, so there weren't any modules when Drupal was initially invented, which is probably not all that surprising. Oh, wow. Okay. Um, by Saturday, December 23rd of 2000, we actually had this code. Now, that's pretty big. You might be able to read that. So this is actually module execute. This is kind of the analog to module invoke for any of you who have dug into the guts of Drupal enough to see that. Um, you'll see that it used an awesome global in order to register, uh, hooks out of your modules and then return to string. Um, whether you've succeeded or not, right? Uh, by Saturday, May 5th of 2001, we had this code, which may look very familiar to some of you because it's now named module invoke and it actually checks to see if the function we're looking for exists instead of using, uh, globals in order to register all of this stuff. So as I said, Saturday, May 5th. Happy Cinco de Mayo. Um, that's-that is, uh, trees, by the way, in case you don't know. So, um, module invoke. Uh, this code looks remarkably similar to what Drupal 7 runs today. Uh, there's not a lot of difference here. Uh, in fact, uh, the only thing that really changes is, uh, we get the ability to take more than two arguments through func-githards, which I suspect was introduced, uh, at some point after this function was initially built. Uh, and then, uh, we also do this module hook call, which lets you do stuff like put your hooks into, uh, their own files. Um, anyway. So that was really great, but it-it had some things that came along with it. We had introduced functionally our own namespaces now. When you made a module, you called it views or whatever it was you decided to call it. Uh, no one else could have that, so there's no other invocations of functions by the same name. Um, and so this, uh, came with subsequent module naming difficulties, squatting of namespaces, uh, this sort of behavior. Um, and so just to kind of illustrate this a little further, I'm gonna tell you a sad story. Uh, once upon a time, there was a module named Dashboard. Does anybody remember this module? No? A handful of people. So Dashboard was actually a Drupal 6 module using a number of things, very similar to maybe your own Dashboard within, uh, the-within Drupal.org today. Uh, it was kind of along those lines. And, uh, during the Drupal 7 work, there was actually a, um, a UI mockup for a Dashboard within Drupal 7 itself. And so, uh, I had the good fortune of building a proof-of-concept mockup module that kind of began working towards, uh, that mockup. And I called that module Dashboard. Unfortunately, Core decided to adopt the code I had written, expanded it out further, and functionally killed the Dashboard module. The end. I'm sorry. Uh, so this is not a unique story, but I did this, and it was an accident. Um, I'm sure worst things happened during this period of time, uh, both before and since. Uh, and then we had kind of, um, well, OO class names as a problem space as well. And so this is-this is my-my little game. Whose class is it anyway? Uh, so you declared a class called Query. All hell breaks loose because dbt and g already did that. This isn't actually a Drupal problem. Uh, you can deal with this in PHP today. If you're doing object-oriented code of a certain age, uh, it's likely that you're having to keep track of other people's class names so that you don't write something by the same name. Because we can't have two classes named the same thing. So, uh, all of this that we've talked about thus far really still defines Drupal 7's basic functionality to this day. Uh, everything I've said here is true of Drupal 7. Uh, it's not necessarily true of Drupal 8, and we'll get into that. Um, but as a snapshot in time in terms of what it is that we're actually fighting against, um, both in Drupal 8 and in PHP in general, I think it's really relevant to understand what Drupal has done historically. So let's talk a little bit about PHP. Um, because PHP was doing some interesting things during this time frame as well. Uh, and so, uh, in the 99-2000 time frame, there was a discussion held at the PHP developers' meeting, uh, that conceived of PHP extension and application repository, or what we commonly call PAIR today. Um, Stig S. Becken. I apologize if I didn't pronounce his name correctly. Actually found the PAIR project somewhere around this time. And, um, this is really just a structured library for open-source code, right? Open-source PHP code. Um, we're not at the GitHub layer yet or anything like that, but, um, it was trying to be a distribution tool, a, um, dependency management tool, that sort of stuff. And it's an interesting note that very early on in the Drupal cycle, I think it was, uh, either in three or some early release of four, uh, Drupal actually had an object-oriented database engine from PAIR. Um, we removed that at some point, but did bit for the day. Uh, so why did we end up with modules and not actually adopt something like PAIR? These were things happening at the same time. Uh, you know, I would point to the fact that historically, Drupal has a real not-invented-here syndrome problem that we're only, uh, just now kind of breaking out of and opening our minds to broader possibilities. Um, there's also kind of a question around the early awareness of PAIR, uh, not only within the Drupal community, but perhaps PHP at large. Uh, so adoption wasn't really likely. Um, it also required a peer review process to get anything up there in the first place, and this meant it was very restrictive, and thus not all that heavily adopted. Um, certainly not at the same, uh, at the same scale that we're seeing other solutions today being adopted. Uh, and finally, kind of the, the death knell, if you will, was that it was most useful if you had a root axis. So, um, with that being said, let's talk a little bit about PHP's present. Um, and if you have questions, feel free to raise your hands. I don't know if we, we do have a mic out here, so we'll probably have some time for questions afterwards, but, um, so we are kind of post PHP 5.3, and this has given us something really wonderful, which is, of course, uh, namespacing. Who in here's actually used 5.3 in namespacing and stuff like that at this point? That's a pretty good chunk of the room. Um, if you haven't, uh, this changed a number of pretty big problems for us. So, uh, we have a few of these within Drupal today, but just as some examples, uh, like the Drupal component is a namespace, Drupal core is a namespace, Symphony HTTP kernel is a namespace, uh, et cetera, et cetera, et cetera. What this actually means is that based upon the namespace that sits on a class name, we know where to find it, uh, which means we can do a lot of interesting things like auto-loading and, um, you know, building class maps and that sort of stuff. Uh, but this means that, you know, if Drupal component has a query class in it and Drupal core has a query class in it, they don't conflict because they actually have different names, even though you think of them both as being the query class. Um, Composer. Who in here's used Composer? Yeah. Good chunk of the room. Okay. Uh, so Composer. A couple of quick definitions here. Uh, Composer is what I was mentioning before. It comes with an auto-loader by namespace. Uh, there are a number of other auto-loaders out there. Uh, Composer is just really convenient since you also happen to use it for package management and dependency management. Uh, so you kind of get this auto-loader for free to a certain degree if you choose to make use of it. And Composer's not as strict as Pear. Um, which means that it's been much more heavily adopted. There are a lot more projects using it. Uh, and ultimately, you know, that's much more kind of the open-source way that we are used to in these terms, and it's been much more widely adopted. Now, all of this stuff is kind of conspired together in order to give us, uh, what I'm going to term interoperable components, right? And when we start talking about interoperable components, we have to look, uh, at, uh, kind of, uh, you know, this was the definition I was giving before, because we have these namespaces. Um, we can have overlapping quote-unquote class names, if you will. I can have query, you can have query. We can all have a query. Um, and that's very nice, uh, because, you know, we can, we can not worry so much about what we're naming things. And this means that we can have lots of, uh, components that can stack on top of each other. We can declare dependencies through Composer, um, and actually manage these things. Um, I've made mention of both of these things. So, um, I'm gonna get into both of these topics a little bit more, but there's been kind of, uh, an organic contribution in community evolving around various components. Uh, so, um, you know, Symphony, we've adopted it, right? Uh, many other projects have begun adopting it, so that's kind of organic. And then there's, uh, various formalized communities. I'm gonna talk about two of these, um, that are perhaps a bit more focused on either a specific component or on something that PHP can do to better the integration of these components. Uh, the first of these is actually PHP-FIG, who in here is familiar with, uh, the PHP Framework Interoperability Group? Okay, uh, that's less people, so I'm, yay, I'm teaching something. Awesome. So, uh, FIG stands for Framework Interoperability Group. Um, now these guys are dedicated to creating standards that any PHP project could adopt. Uh, and the first of these is PSR0. Who in here has heard of PSR0? Right? All right, for those of you who haven't, it's a class autoloading standard, uh, which is, again, kind of what we were talking about by virtue of the fact that a class has a particular namespace on it. We can know where it resides on disk and load it without having to do, uh, awful things in, say, I don't know, an info file that tells Drupal where every single class exists. Who in here has done that? Right? Um, so Drupal 7 has kind of its own, and before has kind of its own class loader. In Drupal 7 this works by saying, oh, I have this class, and I have this class, and I have this class. Um, you know, if you've ever seen that files, uh, notation inside of your, your, um, modules info file, uh, that is specifically for this. Uh, it is to say, here's a class, and here's a class, and here's a class. Or here are files that hold classes. And then Drupal goes through and finds all the classes that are in all of those files, so that when you say new, whatever the class name is, it knows where to actually load the code that will run that class. Uh, FIG has done a number of other ones as well. So they have a basic coding standard, uh, a coding style, uh, a logger interface, and finally, uh, the most recent one that they have put out is improved autoloading, PSR4. Uh, anybody in here familiar with 4? Yeah? Yeah? All the same hands. Uh, it, yeah. We're not gonna talk about 4 right now. So, StackPHP. Who in here's heard of StackPHP? Really small group. Okay. StackPHP is a group who is collaborating specifically around symphony HTTP kernel. Okay? Now, Drupal uses symphonies HTTP kernel. Uh, PHPBB uses HTTP kernel. So does Laravel and a number of other of these systems. And, um, so what StackPHP's really doing is they're encouraging framework-agnostic HTTP filters. Um, and this could manifest in a few different ways, but to my best understanding, what they're attempting to do here is actually make it so that these things could hypothetically function during the same PHP process, during the same PHP request time. Uh, and your router could send some things to PHPBB and other things to Drupal based upon what the, what the needs of the request are. But all of this stuff could exist in one place. Um, it's a really interesting approach. Uh, you should definitely check it out and read more. They have a number of other things that they do around, um, some interoperable things. Um, so finally we're gonna kind of get into component libraries a little bit here, and then we're gonna start getting into the really interesting stuff. So, uh, for purposes of discussion, I've kind of defined component libraries as, uh, anything that is a lot of PHP components grouped together. Uh, so Symphony would be amongst these Doctrine, uh, Zen Framework 2. Uh, all of these have a number of different components within them. Uh, so Symphony, you know, has HTTP kernel. It's got, uh, the routing layer. It's got YAML. Um, Doctrine has Doctrine Common and its whole ORM system. And so these are groups of components, uh, meant to be used either as a group or allowing you to individually pull pieces out of it. So, having kind of laid the found work for the, the foundation of this conversation, I want to talk a little bit about where we are today with Drupal. Um, because Drupal is really a mixture of modules and these PHP components. Um, Drupal 8. I understand everything I'm about to talk about is all Drupal 8. Um, in the same way, we're actually a mixture of OO and procedural approaches within our code base. And, uh, we've done a bit of a, uh, conversion to stateless services. Uh, anybody in here hearing talk around either the dependency injection container or service container in Drupal 8? Uh, this is what they're talking about. Um, stateless services, things that you can ask a question of, and it doesn't matter how often you ask it questions, it can, it doesn't hold state for the answers that it gives. We have a number of unexposed generic PHP components. And what I mean by this is that during the Drupal 8 development cycle, we actually spent, um, a lot of intent and a lot of time building up components that could be given back to the PHP community. Uh, so there's an entire directory structure for this stuff. Let's see, I don't remember my next slide. Uh, yeah. There's an entire directory structure for this stuff inside of Drupal components. I've made mention of that namespace a few times. Anything within that namespace is actually something that we would like to see publicly available to the rest of the PHP community at some point. And in fact, there are two of these components that already have composer JSON files in them. So if we were to do a subtree split inside of Drupal's repository today, we could begin serving at least two of those out to the rest of the PHP community. I think it's really interesting as a number of implications around licensing because we're gonna license everything that we send out, GPL. Um, but it-it's also really interesting because I've already found projects out there that could benefit from some of our components. So, Drupal's future. Um, I honestly believe that our future is standardized PHP components. Um, I think that we should be looking towards these more and more. We're seriously considering what it takes in order to share them with the rest of the PHP world. Um, as I mentioned just a moment ago, we actually have two of these that are ready today. Uh, component utility and component plugin are both tools that could be used outside of Drupal right now. Um, I've been testing with plugin because I was one of the primary authors behind it. Um, but I've been testing just in my own kind of symphony stuff and playing with it. And it's great. It's great outside of Drupal. Uh, and-and we have a lot of other things that could go here. Uh, dbtng, uh, our database layer, for those of you unfamiliar with that terminology, uh, has been pretty close to being a generic PHP component for a very, very, very long time and with a little bit of effort could be served in the same sort of way. Um, I-I think that we need to start advocating for a Drupal's second approach to all of this. And, uh, I mean that in the kindest way possible, when we do core development today, a lot of times we-we spend a lot of effort around, well, how does Drupal need this? Um, and so much time and energy goes into doing that. And I feel like if we were to take time to say, how would this work without Drupal, figuring out how it works within Drupal is-is something that can be part of the process afterwards. Again, we've done this with plugins. We've done this with a number of different, uh, tools. But there's actually a additional directory structure under here for Drupal core. So we have Drupal component plugin and we have Drupal core plugin. These are two different namespaces. But the core system actually extends the component system and embeds Drupal-specific logic into it so that this can be reused by, um, by non-Drupal systems and Drupal can still have what it needs from the system. So these are dichotomies that we can absolutely establish and we can maintain, um, that they can be very useful to the outside world. Uh, and I would actually advocate that we are moving towards a world where there are no more modules, where what we actually do is we build PHP components for everything. Uh, so this might actually mean that in the not-too-distant future, someone could add to a composer file that they want to use Drupal views. And Drupal views says, well, I need Drupal entity and I need Drupal dbtng and I need, and I need. And all of those come down with it. And once that starts happening, we've got half of our code base running in generic PHP projects. And so I'd just like to pose a question. If they needed support on that, who would they come to? Right? We all go to the people who actually maintain the code when we want to ask a question. You know, if we dig in and figure it out for ourselves, we're gonna bring in more people to the Drupal community. They're gonna be using our code in broader ways. And it's actually gonna grow our community as a product. Um, I would also say that there's kind of a detail around the fact that we do multi-module packages today. Um, actually meant to look this up because I think Symphony does this right now. I think you can actually get all of Symphony from a single component statement. Um, or you can get individual subcomponents of it. Uh, so there might be some details around this, but, uh, really, this is here just to point out that there are things to figure out here. There's a lot of stuff to figure out here. Um, but I think that it's a very doable thing. Um, that's small, I know. Does anybody know what we're looking at? Yeah, it's a composer JSON file. Specifically, it's guzzles, composer JSON file. Um, if you haven't looked at a composer JSON file before, I just want to point out a couple of things. Here's its name. Here's its description. Here's its author. Here's its requirements. Does this look like anything to you all? Here's its class auto-loading. What? I heard someone say something. Does it look like an info file to anybody else? Yeah? They have everything we have in Info Files and more. Like everything. I would challenge you that this is an info file, right? Um, we can actually begin actively using this stuff. Um, I'm gonna tell a quick story here. Uh, anybody familiar with OMBED? Like, as a technology, right? If you aren't, OMBED is something where you could say, oh, hey, this Twitter link, right? I'm gonna just paste it in my text box and hit save. And then instead of having a link to Twitter, you actually end up with the Twitter tweet and, you know, follow links and all of that sort of stuff. Same thing with YouTube videos or Vimeo or anything like that. Um, so I have a dark little secret. I've been playing with WordPress. Um, they do this really well. They do this really, really well. Did someone call me a traitor? I am. What? Oh, not yet. But I'm obviously working on it. Um, but they do this really well. I mean, you can just stick a link in there and hit save. Boom, it shows up. So I'm not gonna be that hard. So I go looking through their code. They have the same problem we had. If they didn't invent it, they need to. So they wrote all of these classes to take care of this stuff. And I was just like, I'm running Drupal 8. Why don't I go see if somebody's already done this? And so I went out to Packagist and I looked for OMBED, and I found a project that had like 30,000 people using it, or something like that, and I downloaded it. And in about, like, 5 to 10 lines of code, I had written a filter for Drupal that did this. I didn't have to maintain any of the critical pathway of code. It already had a solid user base, and I was just like, wow, that's way better than writing a whole module system, or a whole module to do this sort of stuff. And we get this ability now, and we could begin actually benefiting from other people having that ability with our code. By the same token, I then turned around and started looking at that code and thinking, wow, if I could integrate plugins into this, I could get something really, really cool going with it. So I have some final thoughts here, and I know I'm really early on time, and the reason for that is I'm hoping we can actually have a bit of a conversation about this, because I'm sure there are some questions regarding it. But Drupal has built and maintained a solution for the last 14 years before PHP had a similar, widely adopted solution, right? So modules are, frankly, way ahead of the curve. We did this literally 14 years ago. Give or take a few months. PHP, though, is really clearly caught up with us with a very similar solution. And I think that it's worth noting that I think there's some things about their solution that are actually better and stronger than what we've done. I've hit on this topic many times. If Drupal adopted this, we could see much greater adoption of our own components outside of Drupal specifically. And I think that's a really important point to make, because I think, you know, I termed this as a post-PHP renaissance world. Like, this gives Drupal a very clear future post-PHP renaissance. But I'm gonna ask a question, and I'm gonna pick on WordPress a little bit here. In a world where the rest of the PHP world is Alucard building the systems they want from components they know and trust, what PHP project has a future if they can't conform to that, right? Do we actively see more developers who are learning PHP wanting to come join our project if we aren't adopting the PHP standards of the rest of the world? I don't think so. I think that, you know, some projects might have a very small, very defined core of people who continue to push them forward until they burn out. But if we want the greater power of the PHP world at large, we need to adopt what they're doing. And I'll tell you, this is a quick, should have put this on the slide. How much of the web is run by Drupal? Anybody? Yeah, it's 2% is what we typically say. And what's the number that WordPress is running? It's, like, 23? Something like that? Anybody happen to know what the number for PHP is? I was gonna say 83, but it's huge. Now, granted, all of that isn't going to be this, but it's progressively moving towards this over time, right? 282. We'll go with the more accurate number here, right? We're talking, like, 40 times the difference, okay? That's the potential crowd that I want to take our code to. So I'm just gonna kind of open it up for questions and comments at this point. I think we've got 15, 20 minutes, something like that. I've run through my slides pretty quickly. So there's a mic here and a mic there. If you have questions, please... I know it's not a core conversation, but I'm gonna pretend it is for a minute. So what I always thought about this is, right now we have the distinction between what you download and what we enable. So Drupal has this database where it says, with this module it's enabled, this module is enabled, and this theme is enabled. And even if you still have the code downloaded, the module can still be disabled, and this will have an effect on your side, whether it's enabled or not. And in Composer, if you download the libraries, this is not the case. And also that's the distinction between a package, which is what you download, and then the module, which is inside the package, which can be multiple modules per package. And even if we do everything else with packages, wouldn't it still make sense to have some stuff that can be enabled or disabled? That could be maybe in the Composer JSON, it could be Drupal, and then there could be some... which modules are in the package. Yeah, that is absolutely a thing that could happen. A couple of quick clarifications. Drupal 8 actually doesn't have disabled modules. It has installed modules and uninstalled modules. That's all it's got. There's no disabled there anymore. So if you want to turn it off, you can use your data. But to your question, and I think it's a really good and very insightful question, have you worked with, like, Symphony Fullstack or anything at all? No, just Composer stuff. So it has, like, kind of the same sort of approach. They have this bundles thing where you have to go and actively turn bundles on and off. But the simple fact of the matter is is that Composer actually knows about those classes. So even if you don't enable a bundle within Fullstack, Composer can still load the classes. That's actually true to a certain degree within Drupal today. The only reason it's not true is because we add the namespaces for all of our modules in a really funky way instead of hooking into Composer and actually compiling them properly into it, which I think is something we should probably do in the long term. But your point is well-made. I guess my answer to that is simply, yeah, but Composer could probably load those classes, whether the module was enabled or not, right? So that really just becomes, like, a boolean, are we actively calling to those classes and making them fire if it's, like, an event subscriber or something like that, or not? It becomes, like, that level of a question, not an access to code question. I think that maybe what it comes to is that package would be something more important and module would be something less important. Module would just be functionality that is either active or not active. Yeah. It's maybe with install and with data and stuff because you need to have the code before it can install anything. Yeah. And also to uninstall something. You still need to keep the code around. Right. I'm not standing up here saying I know all the answers. Like, I think this particular one is actually one of the nuances that's gonna need some actual work. Yeah, but maybe it also helps to think about it, not replacing modules, like module development in Drupal 8. What would be the best approach at the moment to separating components out of the module itself? Something like, I don't know, thinking about symphony, they usually split the library itself from the bundle. Sure. And doing something similar, like, I don't know, a smaller composer JSON file within the module or stuff like that. Stuff like that, yeah. Well, you know, this goes back to Drupal 2nd. Like, I think we really need to adopt a really, um, a very principled look at our code and say, what of this is not Drupal specific, right? Drupal really is a combination of a bunch of things that we all like, how they work together, right? And that's very good. It's very good for us. It's very good for the message of what Drupal is, I think. Um, but, yeah, I mean, you're right. I mean, in that world, do you release the generic tool separately on GitHub and just write a Drupal adapter for it? Like, I did in my previous video, and I'm not suggesting that everything's going to adopt this. Like, we may find that, by and large, people write Drupal-specific things and don't worry about writing an adapter to a more generic tool. But, um, but, yeah, you're absolutely right. I mean, in that world, do you release the generic tool separately on GitHub and try to write a Drupal adapter for it? Like, I did in my filter example, or, I mean, what's the answer? Again, I don't really know, but I think that something along those lines is likely to work. So what would be your recommendation for, like, today to tackle this problem? I would attempt to write generic libraries with Drupal modules as an adapter. That's exactly what I would do. And how do I require that within the module? Uh, that is a very good question. Um, so I, actually, who in here has used the Composer Manager module? Anybody? Okay. I'm going to just say I haven't. Um, what I've been doing is I've actually used hook requirements in order to say, hey, does this class exist? And if the class exists, then I allow it to be installed, and if the class doesn't exist, then, you know, I've got a hook requirement statement telling somebody, hey, you need to go install this, um, this component. So the course Composer JSON is really, really ugly to probably do, uh, but that's what I've been doing. Um, can you speak to what Composer Manager does in this regard? Anybody who actually knows? So the Composer Manager module basically takes, looks into every module that has a Composer JSON file, and it combines them together, and then it looks for some other common dependencies, like Symphony and Guzzle and Zend, I think. And then it will, it's a little quirky, because it's, ideally, you know, Composer is supposed to be one Composer file. So it will, you have to run Composer, and then it will basically create a separate vendor directory that it will now use in addition to the core vendor directory. And this is, uh, you know, in contrast, if you, if each module had to run Composer, you would end up with duplicate code all over the place. Right, because that's supposed to happen when you do the Composer install initially that builds whatever it is you're running against. I'm just gonna point out that this weirdness exists primarily because Drupal's in a funky state right now. You know, if we were to have gone one way or the other, we either wouldn't have this option at all, or we'd be doing everything strictly through this option, but since we're kind of in this gray middle ground, your solution is probably gonna be a little weird. Uh, for testing purposes, I would add it to the, to the core Composer and just do a Composer update there. Um, your final solution might look a little different. Yeah. So there was a decision to bring Symphony into Drupal quite a while ago now. Uh, Symphony's already got doctrine, which is a very good, um, alternative to the DBTNG and offers quite a lot more. Do you know why that wasn't brought into Drupal? And, um, is there any downsides to that? Is there, is there a good idea? What do you think about that? Larry, are you in here? No. Uh, I would let Larry Garfield actually address that. My understanding is that, uh, DBT and GA actually is, um, has more functionality than D-Ball does. Um, D-Ball, right? That's its name. Um, yeah. Anyways, uh, that would have been a pretty radical alteration of yet another major component of Drupal. Uh, so I think that alone is probably a good enough reason not to have attempted it this time. Uh, but, you know, we also have a really, really robust solution there. So I think a lot of consideration would have to be made before we, we decided to go with some other solution. Um, because what we have is certainly no slouch. Okay, thanks. Yeah. I was just wondering when the, when we have all these components, uh, which I think is a very good idea to, to share with everybody and take in from the rest of the PHP community, not just the Drupal one, how would you think that we can avoid the trouble of shifting responsibilities? Like, uh, I have a problem with this module. Yeah, it's in the component, which is based on another component, which is using an external library and then nobody takes any responsibility for it. Or somebody is changing it and then it flows down the chain and then suddenly the Drupal module breaks. Yeah, sure. Yeah, I mean, upstream has always been a problem in this regard, but I, uh, would challenge you that we have exactly that problem today. Uh, any panels users in the house? Yeah. Yeah? Have any of you ever filed an issue against panels? Have any of you then subsequently been told that that was actually a page manager issue and not a panels issue? Okay, I have at least one or two people who still have hands raised. We have this problem today. Um, like, fundamental... I was just thinking that it would be even larger when 30,000 users have somebody... It might be. Um, I fully acknowledge that. Um, I'll also point out that we have that problem now, no matter what. Right? Yeah, but we have a good idea as to how not to have the world to solve it. Well, I guess what I'm proposing here is as developers, as Drupal developers, right, we should adopt a Drupal second principle here. So, even if you didn't, like, let's suppose nobody listens to me and everybody continues to just go Drupal, Drupal, Drupal. Drupal. Um, you're still dependent on the same dude. It's just where he toasts in the code. Right? Yeah, well, I totally agree with you. I was just wondering if you had some good ideas. No, uh-uh, that's a hard problem. Okay. Yeah, but that's... There's some truth to that. And actually, who in here uses Drushmake? Ah, good. My people. Of those of you who use Drushmake, who pens versions? All right, for those of you who don't do, this will save you much heartache and pain in the long run, because if you're just running against Dev or you're just getting the latest commit from Git, like, that is a serious, serious, uh, recipe for heartache in the long run. Um, and so I'm gonna point out that Composer actually does this to a certain degree as well. And if you, uh, have worked with Composer and you wonder what that lock file is, uh, that's what it is. It's actually there to help make sure that team to working against the same Composer system can get exactly the same code base all the time, uh, one against the other. Do you have another question? Uh, just wanted to say, like, the semantic versioning in Composer helps, like, to restrict the version that you want so you don't get some future version that's totally out of API. And then if you're not happy with some, um, library can clone it and fork it, that's not so easy with Drupal modules, and these libraries are supposed to be more decoupled than Drupal modules are nowadays. Right. So this would make this problem a bit easier, I hope. Yeah, and actually we did this in, um, in Drupal Core. Uh, if you open up the Composer JSON file in Drupal 8.core, what you'll find is that there are certain components where we actually depend on a specific, uh, Git commit hash, um, and we've actually notated that in there so that we get a very particular version of, I think it is Doctrine common, um, and maybe one other, um, because we had some specific improvements that we wanted to make to, uh, the annotation system within that so that, uh, we could get better debug messages or, or better error messages out of Drupal. Um, are there more questions at all? No? Okay, I'm gonna let you go just a little bit, uh, early. Um, I would ask you to please rate this, um, and I'd also, oh, hey. One issue was how realistic is to get a lot of this in Drupal 8 or would we need to wait for Drupal 9? You know, I think that's a really great question. I don't believe that any of the modules that are sitting in Drupal 8 are likely to get their own Composer files. Uh, there are also, uh, extra approaches to this. Um, for example, there are people who have built solutions where they can compose together all of Drupal from a Composer file and Composer's pretty robust in this regard. Like, there are things that can be done in order to actually, uh, tell it how to get modules or those sorts of things. So there have been people playing with this idea to a certain degree already. And we may find that somewhere in that middle ground is where we ultimately end up. But, um, you know, raw, like, Composer? No. Not today. Not during the 8.0.x cycle, for sure. I doubt we'll see it until 9 at the earliest. Yeah, and then it has been a traditional thing in Drupal to have, like, an FTP connection and to upload your zip files, a step-by-step, and with Composer need to command-line and download itself. Yeah, I doubt you have to do that locally and then push it. Okay. Right. But you're totally right. I mean, typically, um, I think typically you're looking for a build process that'll do that work, though, so that you say, hey, I want these files, and then there's, like, a build, uh, process that happens, and then puts that code where it needs to be at the end of the day. Um, you know, there are a number of different solutions that could be put in place for that. So, um, yeah. Yeah, you're just gonna get a constant stream. No, that's good. We got time to kill. So, I'm thinking, like, um, the Drupal second approach that you're talking about, it not only, as you've said, involves thinking, is this something else that can fix the problem other than, uh, you know, I don't have to do something Drupal-centric. Also, when we're solving problems, can we solve it in a way that would benefit the wider community? Right. Um, and then, I know it's not, like, directly relevant, but, um, how do you feel about the fact that we were distributing our code on Drupal.org when the wider community is doing it through things like GitHub, and, you know, how do you feel about that? I don't think it's an issue at all. Um, you know, you look at something like Packagist, and it doesn't care where the Git repository is so long as it can get to it, right? So, two... No, it doesn't have a problem, but what about just in terms of... I don't know. Like, in terms of bringing in new contributors? Yeah, that's it, yeah. I think that's a much larger discussion, um, and it's one I don't really feel qualified to, to speak to too much, um, but I'm never one to hold back on my opinion, and my opinion is essentially that, you know, Drupal.org is what it is for good reason. Uh, that's not to say it couldn't be improved because it certainly could be. Um, and there are a lot of people who have a lot of ideas about how to do that, but, you know, we've centralized our community there for a very long time. Um, and, you know, in the past, I've said, oh, it'd be great if we worked like GitHub. Um, I've never really advocated moving off of Drupal completely, or Drupal.org, uh, because I think that Drupal.org is a really powerful place to centralize around. Uh, but there's also a lot of that that happens, um, you know, in IRC, uh, but I think having, like, a singular issue queue, you know, if I say, oh, it's project such and such, right? Well, in GitHub, what do you gotta know? Well, you gotta know whether or not I maintain that code, whether I fork that code, what my username on GitHub is, and what that project name is. On Drupal.org, you know, it's Drupal.org slash project slash whatever name I just told you, right? So, I mean, like, there's some benefits, I think, to just being centralized in one place and knowing where our stuff is. I think the same thing will be true for PHP libraries that can be used on their own if they're Drupal. Um, and I think one of the other really big benefits there, uh, and this is a really big conversation, uh, that I'm not gonna do right here and now, probably. Uh, but anything that goes up on Drupal.org is supposed to be GPL2+, right? That's the license it's supposed to be. The rest of the PHP world is adopting MIT and BSD and I think that, um, I think that we should really consider, uh, not changing, I think that we should really consider what it means to offer BSD components to the PHP world at large. Because BSD, uh, not BSD, I'm sorry, GPL components to the PHP world at large. Because what GPL does is it actually protects anybody who uses our code. That's what GPL does. BSD and MIT protect us. But we get that same protection from GPL, right? Um, I mean, if you really go and you read these licenses and what they're about, it's about whether it's protecting us and what we can do with it or what end users are doing with it. And Drupal's always been GPL and for good reason. If we started releasing GPL components, PHP generic components into the world that were of exceptional quality, I think we might start a really interesting conversation with the larger PHP community. Anything else? Well, anything else? So, uh, please write. It's node 1573 on, uh, the Drupalcon site. Um, and also, I just want to invite everybody in here. Uh, Acquia's doing a developer meetup tonight from 6.30 to 7.30. Uh, but I'm not gonna try to pronounce that. But it's the place right behind the convention center. Um, so if you'd like to come, please feel free to. Uh, just kind of an open invitation. And, uh, I don't have anything else. Thank you very much.