 In discussing this, we really wanted this to be more of a conversation because I think there's a lot of open questions about where we're going with search in Drupal Core. This is really just about Drupal Core, not about contributed modules. We're going to have a buff relating to GeoSearch and Apache Solar afterwards and therefore if you see me running at five o'clock down the street, that's where I'm headed. So I changed the title on this rather than focusing on sort of adding to Core. I thought it would be useful to pose the question, what's useful currently in Drupal Core search, what's missing, and what's excessive that we could get rid of and make Core simpler. So to frame the problem, thanks, this is basically Chris's framing, that when users come to your site, what they expect is something like the Google experience. So they're expecting an or search, the page to come up first has the most keywords matching, they expect something like a stemming or a little bit fuzzy match, so they don't have to type the exact word. They expect some kind of spell correction or suggestion for spelling. Expect keyword highlighting and they expect that every page on the site is going to be indexed, at least if it's publicly accessible. So Drupal Core misses out on quite a number of these things right now. Just almost all of them in Core. Maybe number two, the most relevant page has the most keywords, that's about it, right? So there's a lot, you know, Drupal, you know, and just, you know, and we have highlightings, keyword highlighting that usually works. So not always, but it's there. So we're missing out on a lot of this. So I think, you know, users coming to use a Drupal site, run the site search, it doesn't work the way they expect and, you know, that's going to lead to some dissatisfaction to feeling like Drupal doesn't have a good search, even if the algorithms behind the scenes are doing a good job. There's also, you know, if we go beyond the Google experience, we think about a more rich site like an e-commerce site or something like Amazon.com. And this not only has that keyword search box, but it has a lot more features that help you find what you're looking for. So one of these that Chris is very interested in, and he can grab the mic if he wants to talk about it, is progressive disclosure of facets. So this is if, as I start to drill down, new facets become relevant. So it might not have been relevant when I'm searching the whole site, you know, but once I've gotten into the particular, you know, general category of widget, maybe I want a facet block about colors. Now I didn't want colors, all possible colors for all products on the site. I only wanted the colors, you know, the 10 colors available for, you know, men's t-shirts with the Drupal logo on them, right? So that's all I want to see. So we have to know when it's, we have to sort of intelligently figure out when, you know, those sites are able to intelligently know when to show you new facets that are relevant to your search. They have better widgets for facets that maybe make the navigation a little more intuitive. They have more, you know, ways to target the searches. So if you think about Amazon, you can search within a department like books. So, you know, if I search for Drupal, Drupalcon, I want, you know, a book about, you know, the history of Drupalcon. I don't want Drupalcon socks because that would be a different department. And I know I don't want socks, I want a book. You know, obviously they have good keyword matching, you know, this follows sort of from the Google experience and builds on top of it. And we have some kind of, you know, similarity or, you know, recommendations is often part of the site. So we think about a really great search experience. I would not only have the Google experience of great keyword matching, but we'd have all these things built on top of it. And so clearly we're going beyond Drupal core here. But for Drupal 7, you know, there's really not a coherent way yet in contrib, I would say, to achieve these goals, to sort of match the Amazon experience. Then we have another problem. How do we maintain even Drupal core, the keyword search? You know, so right now I think it's fair to say that no one is actively maintaining the core search module in Drupal, certainly in Drupal 8, Drupal 7, Drupal 6. You know, there's a lot of open issues. And I think this is true for a lot of areas of core. I'm not, I mean, this is a general broad problem. So, you know, things that I'm listed as a maintainer of in Drupal core, like I don't have time to look at the issues keys. And for specific to those things. And, you know, but it's a problem even that there are patches, you know, that are ready to go and are not getting reviewed. And there's also in core search it has functionality that's not used very often. So, how many people here regularly use the advanced node search? How many people here use Boolean searches, like actually typing and and or? All right, we got one. So, you know, those are things, you know, they're nice to have, but really do we, you know, is that important to ship in Drupal core? There's also, I think, a problem in sort of the way core search is set up is the boundary between what search module is doing and what the node module's implementation of search is doing are a little fuzzy. And some of the stuff in the core search module seems to be catering very much to the node module implementation. And I, you know, that's sort of an architectural problem that we might want to deal with and try to make a cleaner separation. So, you know, Drupal, we know, has the capability to have a good site search. And, you know, the challenge for us is really to make the out of the experience, you know, the Drupal experience either out of the box or with contrib modules better than at least the Google site search, right? So, there are problems with something like a site, Google site search. So, why not just tell everyone, you know what, Drupal doesn't come with search anymore. Google will take your money, index your site with a custom site search, and, you know, we're done. We have no more maintenance problems. So, you know, what are the problems with Google site search? You know, what can we do better? If you have a crawler, you get everything on a page. So, you get, you know, the sidebars, the header, the footer, you know, if there's a certain word that appears on every page of the site, well, that's going to tend to come up in every search result, if you look for that word, right? Google doesn't know how to exclude certain content. So, you may have certain node types that shouldn't be in your search index at all. But, through whatever way, if it's crawlable, it's going to show up in the search index. So, an example might be if you have some kind of composite pages composed of multiple nodes, you don't actually want each individual node showing up in search results. Google can't facet on internal metadata. Like things like author name may be, it could figure out. But, you know, there's a lot of internal structure and data about the node that we can use to create those intelligent facets. And Google clearly can't provide your authenticated users, you know, access to private content in search results. So, you have to be within the Drupal user system, the Drupal authentication system in order to do that. And clearly, for a lot of sites, searching private content is a key feature. So, we can't, we don't want to abandon a built-in search solution. Yeah, these are some of the limitations that something like Google has that Drupal can do better. All right, I think I'm going to make Chris talk about this. So, just a dirty secret, I shared a book with Peter last night and then he stole this quote from the books. So, you know, I think right now what we do in Drupal search is, you know, we don't really focus on best practices. We don't focus on what other people are doing. And there's a lot of good examples. I think a lot of times what happens is that core search kind of gets in the way. So, what we end up having is we have sub-projects, right? So, we have a search API. We have, you know, core search, people that still use core search. We have Apache Solar, you know, for Drupal 6. We had search scene APIs. These are different ways to attack this problem. And, you know, I think the big thing is how can we make big best practices easy? There's a lot of patterns out there. And I think, you know, the big argument here is does Drupal core search need to be everything to everybody, right? Or does it need to be handled in contrib? Because Jennifer, I'll put you on the spot here. But if you can describe, if you can say one word to describe the patch committal process in search, what would you use? Now, keep it clean now. Yeah? It doesn't exist? Right. So, you know, I think the big thing here is how can we enable contrib modules to start to work together and to make sure that that search doesn't get out of the way. And to make sure that the core search module is able to get out of the way gracefully. You know, I mean, I think there's areas where we say, okay, you know, how do you tune search weightings for optimum relevance, right? Would it be nice for core to understand this? Yes. Would it be essential for Drupal core to do all this functionality? No. But should it provide a way for people to do it? Yes. And then leave that out in contrib so that we can bypass this nonexistent patch queue process which we have. And, you know, the end result is how do you find the user, how do you help the user find the desired results instead of just ones matching the keywords, right? There's a lot of different ways to attack this problem. I think that if we're going to focus big efforts on core, it's going to be really tough to get in. You know, just an example, I'm sorry to pick on you again, Jennifer, but Jennifer had a great patch which ended up fixing the highlighting for word stemming. And it's been sitting in the queue for a very long time. Two years, that's it. Nice, nice. So anyways, you know, if we can allow core search to kind of get out of the way and allow that type of contribution to happen in contrib, then that would really help, you know, move things along and get us to where we want to go. Do you want me to keep going? Sure. All right. You know, I think so, so my big thing is, you know, Drupal search ends up becoming, I want it to be a selling point, right? I want people to say Drupal search is a differentiator when we're talking about Drupal over other CMSs. So, you know, there are some things that we have to focus on. So, you know, basic keyword search has to conform to expectations. People have expectations going in. It just needs to be very simple. You know, I think for the majority of users, you don't have to get really complex. We have a lot of complex logic and core that could, you know, be stripped out and be handled elsewhere. It also has to be customizable, right? The user interface I think is the most important part because there's a lot of work going on in the back end, which is great and very necessary. But users are really focused on the front end and that's what they see. That's the search experience they have. So, again, if we can move that out of Contrib and have some pretty, to Contrib and have some pretty interesting things going on, then that kind of facilitates moving Drupal search forward. You know, I mean, obviously, you know, we need to make sure that we have the documentation, the tutorials available so that, you know, they can, people can learn how to use this stuff, you know, and that happens really by working together. So, you know, I think we're starting to see some collaboration. So, we're starting to see, okay, what are the areas of these big projects that we can actually pull together and start working on together so that it works across all projects? And when that happens, you know, we start, we stop writing one-off solutions and we start writing stuff that's reusable, which will facilitate, you know, more contributions in terms of how to use this stuff. It will be familiar across the sites and in that case, you know, Drupal really becomes a selling point. And, you know, I think in terms of the custom UI, you know, that's another part, you know, once you're theming stuff, that has to be ported to, because I think it's really important when we're talking about search experience, if we can start to work together to figure out a way how to, you know, maybe core search. Maybe this is an area for core search to improve, where core search provides templates that can actually be reused in a meaningful way by site builders. Core search templates are okay right now, but people still run into issues, which is why they move off to other solutions. So, you know, that might be an area in core where we could, you know, work together and figure out a way how we can make that useful to all the various projects. Well, so just picking up on what Chris was saying, so there's a couple things. So as I said, theme templates, you know, that's one area. Maybe core could be improved and that would help carry over. People make it easier, you know, if everyone can rely just on the core templates for theming their search results rather than having customized, but we need to make sure, again, that Drupal core sort of out of the box comes close enough to the Google experience. There are definitely some problems. So we just mentioned a stemming patch, but in general, there's problems with language awareness in search. We need to figure out better how to detect, you know, detect language when we're searching, know what language content is in, when it's indexed, know how to match across languages. I mean, those are hard problems. I'm not sure we can solve them in core. We need to at least provide enough information to the search back and that if it can do a better job on this than core, it does. I think also one place that Drupal core right now really falls down and is probably not that hard to solve is that Drupal core only lets you have basically one search tab per module. And that's, you know, we're finding that that's not really what people want. People often want to customize a search. They want to have a search for a section, you know, search within organic groups, search within something else. So you might want to have several somewhat distinct search pages or, for example, on Drupal.org, we have a search within modules. So why is it that, you know, project module has to basically reinvent a lot of the, I mean, in there, they're customizing that the result template a lot. But, you know, you could imagine some use cases like that where you don't necessarily need tons of customization of the search results, but you need to pre-filter. You want to have, you know, your module provide both a site-wide search and a, you know, sectional search within a given section of the site. Search modules should facilitate that rather than right now it just kind of prevents it or you have to work around it. And what do we, we had half an hour? Right, an hour for all this sort of stuff. We won't have time for discussion, so anyway. It's just been half hour, half hour. Half hour, yeah. So, you know, one of the things I think we have to be aware of in core search, if it's gonna still be useful, is that it has to have enough hooks, you know, available that contribute modules can participate in the indexing process, the search process, or maybe allow contribute modules to more readily bypass the parts of core search that they don't need. So, and in terms of the user interface, so Chris has done a lot of work and I have done a little work around the edges of the Fasted API module. And I think. And Thomas has done work too. And yeah, so Thomas has now done work. And in Chicago, we kind of got up and talked about, you know, the notion of making a bigger toolkit for Drupal core search, which might include something like Fasted API. And I think this is sort of one of the things I wanted to have discussion about, is given where we are with maintaining Drupal core search, do we want to actually add any features really into core at this point? Or are we better off actually stripping out as much as we can, you know, leaving a functional keyword search in Drupal core and really not much else and pursuing all the rest in contrived as, is that a better strategy? If we think that something like this should be in Drupal core, what is the timing, right? So we kind of would need to know that it's mature enough as an API, you know, that we've hit the edge cases, that we understand, you know, we're not gonna suddenly hit, you know, this whole area of things we can't do in Drupal eight after we put it into core and, you know, we've frozen the API. So I think that's sort of a timing. If we decide we really want it in core, when would be the time, how do we know that it's, you know, mature enough? And is there demand, you know, are there enough, you know, do the majority of sites want fasted search or do really, you know, the majority of sites want just a keyword search and more specialized sites are the ones that need fasted search and therefore, you know, depending on our answer to that question might influence whether we think we need this in core. And one might argue that adding something like fasted API to core in some form would be a trade-off that you would offer the community essentially for, you know, like removing features like the advanced search form. Now some people use that, you know, but, you know, once you've taken that feature out, it would be better to say, well, we took that out and we replaced it with fasted API. Even if fasted API doesn't give you that same form, if it at least gave you the facility to apply, you know, to build a form that applied filters, if at least you have that ability in core, you could see it as a trade-off rather than losing, just losing features from core, that, you know, so that's again a discussion point, is that make sense to people as a trade-off or is it simply that we should say, you know, let's take everything out of core that is not, you know, the 90% use case, in which case we just remove it without a replacement. You know, and sort of, you know, building on that further, a big challenge clearly we're facing is, how do we maintain search in core effectively? If we, especially if we add new features to it, how do we maintain it? And what's the best way for us as a community of people interested in this functionality to build a good contributing modules in a way that they interact so that we're not, you know, all reinventing the wheel? You know, for Drupal core, I think this is sort of, you know, this is the problem in a way, and unfortunately I'm gonna run out to a buff, but at five o'clock, Randy and other people will be talking more about, you know, maintenance for Drupal core, you know, how do we maintain Drupal core, how do we deal with new projects, how do we deal with the issue queues? But, you know, so the thing I'm throwing out there for discussion is if we remove features, we reduce the amount of code in core, does that make it easier to maintain? Does that make it easier to fix the bugs? Does that make it easier to test? And is that therefore the thing that we should be aiming for on core? Then also does it allow you to make it reusable so that other people, other projects can use it? And then, you know, sort of another thought in terms of the broader search space is who's benefiting from a good search solution? And how do we, you know, sort of make whatever organizations, individuals, companies are, you know, using search, benefiting from a good search experience, how do we get them to reinvest, again, in a sort of a coherent way that we build a good generic or sufficiently generic tools, especially for the user interface? Again, I think the user interface is the hard part of this, you know, we'll go back to that quote, you know, search is the worst usability problem on the web. It's very hard to get good widget, you know, good user interface widgets to figure out how to expose, you know, drill down options to people in a way that makes sense, that help them find what they're looking for. Yeah, that's the hard part. We, you know, we have great search backends available to us as open source. That's really not the problem. The problem is integrating those with the front end to let the user find what they're looking for. So just to conclude here, some random links of, in case you wanna look for some of the past and current discussions on these topics, and with that, I think we'd appreciate your comments and joining the conversation. No need to clap. Let's converse around, because collaborating, can I take a crack at that? You can repeat the question a bit. Sure, so the question is, let me try to simplify and please correct me if I'm wrong, but you know, a big problem is that, you know, a lot of open sources, you know, the it's just scratch, so who's gonna fund it, right? People would love to work on search, but who's actually gonna buy it, who's actually gonna fund it? Does that accurately cover it? Okay, so you know, just to be transparent, I have a saying, I love code, that's why I don't do it for work. So, you know, all my contributions are in my free time. Thomas, I don't know if you're paid to work on Search API or not. On Google Summer Code. Yeah, so Google Summer the Code, so part of it's funded. I think right now there's an interesting, there's an interesting opportunity here in that we have people who are actually contributing and people who are passionate about search and wanna make it better. And you know, I think the big problems with core search right now are that that itch isn't there to scratch, right? So if we can pull some of that out and we can make it smaller and we can move some of this stuff to contribute and maybe rework it to make it some sort of toolkit, then people will be able to contribute more readily without having to expend a lot of effort having to go through the core channels because contrib is a lot easier to contribute to. You know, I couldn't be able to do the work that I did in core, you know, in my free time. It just wouldn't have happened. Well, yeah, and I think, you know, Thomas was great and Thomas actually, you know, reached out and started working with us on Facet API. So this is an example, right? We have different communities. We have, you know, Core Search has a big user base. Patchesolar has a big user base. Search API has a very much growing user base and, you know, Search Lucene API for six had, you know, an OK user base. We were doing a lot of the same things. So what ended up happening is we took out pieces, right? So we ended up, instead of building up a core API from scratch, we took out pieces of Search Lucene API. We mixed it with the faceted search in Apache Solar and then we kind of put it underneath as a toolkit module that people could use. And then, you know, Thomas ended up showing some interest and then he ended up contributing further to the Facet API module, removing a lot of assumptions and now Search API is starting to move towards leveraging that. So I think that's an example of a project which is a toolkit piece, you know, which is done completely in Contrib which is an enabler for all the other search projects. So I think part of your question, Doug, was are we gonna try to remove Core Search in favor of something in Contrib and replace it? Yeah, you asked the question. So you were right. So I think, I mean, I think we were coming into this trying to, you know, come up with a coherent argument and I think Chris and I are in agreement that, and, you know, we talked with Jennifer and with Thomas a bit and that probably at this point we don't wanna try to invest in putting a new API in Core. But rather we should, you know, take out the parts of Core Search that aren't broadly used, you know, because it makes it more difficult to maintain and, you know, try to get it to the state where it can be maintained. Now, again, we have this question, do we wanna add anything back? Do we wanna add something like facet API as a feature? I'm, you know, I wouldn't be in favor of putting like a whole new API in that tries to be fairly broad and functional because I just think we're gonna end up with the same maintenance problem. You know, the code that's there works, you know, by minimizing a little more we may make it even simpler to maintain. We can improve the initial experience by changing some assumptions that aren't, those aren't big patches. So I think if we did those things we could leave Core Search as it is not alone but not make a radical shift, not rip it out altogether. Yeah. I mean, simply because, you know, and I think Thomas maybe can talk to this more. I mean, my impression is that trying to make an API that's very generic across different search backends is hard. And in fact, you know, I'm not sure you can be successful enough that you want to be in core for the reason that every backend has very specific features, right? So, you know, can, do I have to, you know, keep patching core every time, you know, a patchy soler comes out with a new version with new features? I mean, that, it doesn't seem like that's, you know, the direction we want to go or we have some kind of, you know, plug-in that integrates to the patchy soler that integrates to the core then what is core actually doing? Right, to me it's better for core to come with. You have an API that. Maybe, I mean, it depends what you mean better. Right, so I mean, I think there is cleanup to be done in the current API. I guess I'm arguing against kind of starting from scratch. Like, let's basically leave what we have and, you know, marginally improving it to me sounds like a lot less work than ripping it out. Sorry. Sorry, just to add to that quickly. I think that the big thing for me is, you know, not focusing wholly on core search to make it, you know, a full-fledged API just because, you know, we're seeing problems getting small stuff in right now. So, you know, making it smaller and helping it get out of the way better and allowing that innovation to happen and contrib. And once that gets try and tested, you know, it's easier to innovate more quickly and contrib, try things out, break things, you know, iterate again. And then, you know, maybe Drupal 8, Drupal 9 comes out and we can start thinking about it once we have some try and test and stuff. And so make there to be a simple keyword search that behaves more like what we expect from our Google experience with the ability for the plugins to do the stemming and stuff and actually do it right and basically we core of that. And then anything else that we can do and contrib, just let it happen and contrib. Yes. Very eloquent. Much, much more eloquent than I could have said. All right, come up and say it again. No. That's okay. So Jennifer says, you know, basically to... The proposal that we're coming to is basically yes, we should remove advanced search, we should remove boolean parsing and other kind of special parsing and basically leave core search with a keyword search. We should make it do or queries by default rather than and, which it does right now and improve some of the way the hooks are invoked so that stemming could be implemented properly in a contrib module and basically leave it more or less at that. So somewhat simplified, some fixes to API but really actually less code and simpler code than we have now. We're about done, but yeah, do you have a question? Core search implementation that has extension points and you wanna do solar, that's its own thing. If you wanna do elastic search, that's its own thing. Well, so I mean, there's different, yeah, I mean there's different levels of API, right? So core search is currently an API. Apache Solar uses it for things like displaying the tab on the search page. A few uses the result templates. So there are elements of an API there that can be reused and are useful but I think making it so it's a more full-fledged framework for connecting to different search backends, I would say to me doesn't seem worth the effort to put that in core. Well, that's about as good as I'm gonna get it from you, Larry. Yeah, I guess you're coming from core search API right now. I-ish parts, in my experience, are the ones that I have the most trouble with. So if you're talking about, you know, the core search can out of the way and be easier to just do your own thing, that's the kind of stuff that I would be talking about getting rid of, is search has to go up in a tab on this search slash whatever page as part of that core API that means to just go away entirely as far as that. Sure, so I would agree, for example, yeah, I mean we can make simple changes. Larry's saying it's aggravating that search module forces you to put a tab at a certain path. And I would agree, yes, we could probably improve on that. But that's not, to me, that's not a broad API, that's a little bit of fiddling with how it does its- It's not a module-level API. Yeah, so I think Thomas is his turn, so last question while he's coming up. Why are we talking about Apache Solar and forgetting about Sphinx? Because not very many people use Sphinx and there's not a good integration module. So if you want to write a good integration module, I mean more of the work has been done to integrate Apache Solar. It's easy, fun. Yeah. What's up? Another thing, so. You can put this on your head. I was supposed to tell him that he can put this on his head and don't touch anything else here. I'm gonna have to step up. So while we're waiting here, I'll just make my speech because that's the one we're fine. If anybody's on the hotel Wi-Fi, can you get off? I think we'll meet up the group of calling we got on. Okay, we'll open up. Awesome. We'll be at the spring? Yeah, so we'll be at the spring. Okay, then we'll meet there. Sorry, I have to do that, that's fine. Beth, can I dream of your thoughts? I'll be around a lot, but yeah. I'll just post to you. So don't be on the hotel Wi-Fi and lunch will be here tomorrow as long as you're in a building. And I'm just waiting what? The lunch is better over there, though. Well, I don't know what the line is on there. I just thought it was this thing, once you come down there. Hello, I'm Thomas Seidel and I'm gonna talk very shortly about basically the same stuff that Peter and Chris already told you only from, well, kind the opposite direction in which they took it. So, but basically the problem is the same or this is a slightly different view on the problem. We have Core Search currently in 777. It's mostly a product. It also tries to be a framework, but it's not very successful at it. It has very limited scope as Peter said, it's very much is built towards the node search currently in Core and doesn't really facilitate very different solutions. Apache Solar Module currently uses it, as I said, only for the theming part and for the basic UI that there's a tab and a form field, but it really doesn't take much of a search module's hand, search API, it doesn't use it at all. And so it's in its framework part, not very useful, it's mostly just a product. And there's been a proposed solution which has been as linked by Peter several times now on groups.truple.org. And it's to bring a real flexible search framework into Core, which could do all the things really flexible so that it could really cater to all different sorts of advanced search modules, which want to take stemming and highlighting plugins and whatever different backends, different indexing mechanisms, different data sources, index all entities and pages and whatever. It should clearly separate the basic framework and then the backend implementations. Currently, we would have a database backend in Core which does what this Core search does now but only as one possible backend implementation. And then there would be the extra features, the default plugins provided with Core, so that you have case-in-sensitive search and HTML filtering and such things. The admin UI could also be separated from the framework so that a simple user who just wants to go search to work could activate the framework, the backend and part five of this Core search to product which would offer some basic defaults which would ensure basically the same Core search as now, only as an implementation and configuration of this whole flexible search framework. And this will then leave the implementation of these parts to, well, contract modules, which could then replace all these things with advanced solutions. You could then have a real Apache Solar module which builds on Core search and really just replace the backend and maybe adds then backend-dependent features to leverage all of Solar's capabilities. You would, of course, also have to make all these steps pluggable, not just we are hooks, but we are real plugins. You would have a plugin for data retrieval so that you can not just get nodes and here there are, but build the data from different ways which would, for example, also be a page search which could just retrieve pages as they are rendered and the pre-processing would, of course, be pluggable. The indexing part, how the data is really indexed, of course, then the backend, search query pre-processing at the search time. The actual searching would, of course, also be on the backend and pluggable there, maybe, and how the search results are post-processed so that you could have a highlighter plugin and maybe other steps, and all this pluggable in-core will ensure very great flexibility. And here we come to the advantages of this. Of course, there's now, there would be a common standard which all such advanced search modules could build on, in contrary. Code duplication would be reduced, of course, really back in the dependent functionality could, would just be implemented there and wouldn't have to be duplicating into all these other modules. And, of course, another very large plus would be that if a user comes and does a simple search on the site and later wants to upgrade, he really can easily do that and keep all his configurations like they are but just switch out the backend to a patch of solar and whoops, here's now a much faster and more accurate search. However, as Pete and Chris already illustrated, there are several disadvantages of bringing a full-fledged framework into core. One of the points would be that as I said, if you separate all these things clearly, you would have three to five additional modules just for search in core. And, of course, the whole API which would be very complex and do we really need another complex API in core? It's something to think about and, of course, we also would have more overhead for basic search solutions if a user just wants basic keyword search like currently in the background that would be all stuff going on which would really be unnecessary for his use case. And then, of course, what Chris and Peter also said, maintaining something core is way more complicated than maintaining it contrived. So putting such a framework into core would really multiply the maintenance effort by quite a bit, I think. And what they also said, and I forgot here is, of course, that this API would then have to be really good because if you later find out, well, there's some cases missing, then you have a small broken, in a small case, broken API in core and maybe you would have to go and make another contrived API after all which would, of course, eliminate all the advantages. So the rather lame conclusion is that I think Peter and Chris were right. Forget everything I just said. Doing this in contrived, after all, I think is the right thing as really if the API is good enough, it will be used even if it's in contrived only in the cases where it don't need it which would be redundant anyways. And as Peter and Chris already said, it might even be worth the effort to prune some of the attempts at being a framework from core search, prune some features that are currently very used and just fix some of the structures but basically just leave it as it is now and let it step aside gracefully to let a contrived do a better job at it. Yeah, that's, yeah. By nine. I don't know. You know, you've built the search API, I think. Okay, these are three questions, I think. Oh, I don't think I remember that. Okay, the question is whether I don't think that search API is already mature enough to be in core or that it could be mature enough in Drupal 9 or as Jennifer put it, if I want it in core. Okay, so first off, do I think it's mature enough now that's a complicated question. It hasn't been used for that long. I think that we can tell I'm pretty, pretty content at its current level. And I think if for Drupal 8 we could do some API rewrites, I do think that it would be good enough for core but the big problem I'm seeing is the maintenance effort and that we have to be really sure that it's catering to all needs of advanced of other search modules. And I don't know if we can get enough usage in Drupal 7 on time for it to go completely in the Drupal 8. In Drupal 9 when it has been widely used in Drupal 7 and Drupal 8, maybe we can really get it into core but I think that's another discussion for well in two or three years when everyone then says, yeah, search API, whoo, then yeah, of course you can get into core but I think some of the problems remain. I think that's a good analogy with the CCK module and field and if, of course, if search API turns out to be the second most used contract module, then yeah, please put it in the core but yeah, I think some of the problems would remain even if it were so popular but of course as said, if it turns out to be mature and used and popular enough then of course we could make the effort but it would of course be an additional effort and there would have to be enough people involved to really make it viable. So I don't end up hacking together a whole core search module. And no, I don't have the accent. And yeah, so for Drupal 8, I just don't think it's viable. Also with the whole four to six search modules in core it would be kind of a slap in the face to people saying, small core, yeah, so yeah, here's another five modules. I, yeah, for Drupal 8 I don't think it would be viable but for Drupal 9, who knows and no. Of course, we could have just, oh, sorry. The question is if it would be really three to five modules, we couldn't have one module of the API and the other in Contrib. All right. No, that wouldn't be possible or it would be possible but then we wouldn't have core search to product in Drupal and I don't think we can afford that. We have to ship Drupal with some kind of search solution or we could say use Google site search, I don't care. But I don't think that would be a good option. So we would need the framework module, the backend module. So we have anything to store the data on and the thing providing the search. So a search page module which would add the search page for the users and these would really be three modules already then maybe if you want to put it into another module the extra features like case insensitive search and HTML filter which are really needed for core search product if it is to work correctly and the admin UI could of course live in Contrib but that would still be four modules so three additional ones. Thanks. Three by my account but I don't think it's a mathematical problem. No. So you would put the admin UI into the framework module. Yeah, that's what, yeah, we could do that but I'm sorry I didn't quite catch that. Well, with the full-fledged framework there. Yeah, but if you have a simple UI just for core it would have to be a module after all because otherwise you can disable it if you have a proper admin UI. So then you would have to have admin UI module in core after all and but of course you could do that and just have a very simple form for checkboxes. Well the question, so for example for the new database layer there was an assertion that you needed basically three database backends to validate a generic API. Would you agree with search that if you have a generic search framework core we basically have to be tested against three search backends to validate API? The question is that if with the search framework in core with plug-able backends if we wouldn't have to test against all these backends to really verify that this is working and I guess that would be another problem because yeah really without implementations you couldn't be sure and with test coverage you really would have to do that and if you only have one backend implementation in core this would really not be possible. So probably another argument for that. Yeah Larry? But if we then start screwing around with the API and writing it as we usually do something more to the core, then we would still need to bet it against three different implementations. So we need a database, like a database backend a something with a schema backend like SOAR and something without a schema like Elasticsearch because those are three very different approaches. And if we- Yeah, but we can't know that the core and implementation is right. I mean informally you can say, well it's too much for justice. We have to develop those core contributing implementations in parallel with the core version and the core API. And test coverage would be. Especially if just the only core is enough and the core has to fit better. Yeah, that's actually one of the bigger arguments I think for doing the robust framework instead of in core and just in core VA. If you just have a blog you can use this implementation because yeah, doing three full implementations in core would be a nightmare. Of course. And then it would even be useless to have a SOLAR implementation in core when it says, hey, if you want to use that you have to download something else after all, so. Oh, okay. Well, yeah. Thanks all. Thanks a lot. What's that? So that could be a fun fact. Yeah. Yeah. Yeah. Time over. Right. Thank you all. Okay. Thank you, Thank you, Okay, I didn't know he was coming now or I don't know. Okay. Right. Longer one than this fall? I mean, are you adding that to something? Someone's on there? Yeah.