I realize my thoughts on QueryResponseWriters being misplaced doesn't really matter for 10.x and prior.
I think your proposal for segmenting them is fine, but please declare the BUILTIN ones *not* in SolrCore. It's a detail; happy to code review. We can change what's built-in and not over time. On Thu, Jan 22, 2026 at 3:32 PM David Smiley <[email protected]> wrote: > Thanks for discussing these things... > > On Thu, Jan 22, 2026 at 2:05 PM David Eric Pugh via dev < > [email protected]> wrote: > >> However, I wanted to bring this to the larger dev community for >> disucssion. >> Here is what I'm thinking: >> 1) Separate out the existing SolrCore.DEFAULT_RESPONSE_WRITERS that holds >> all the response writers into two groups. SolrCore.ADMIN_RESPONSE_WRITERS >> would contain the json,javabin, prometheus/openmetrics, and maybe xml >> writers as they are used across Solr outside of a core. The rest of the >> writers would continue to live in SolrCore.DEFAULT_RESPONSE_WRITERS. >> 2) Then, migrate DEFAULT_RESPONSE_WRITERS response writers that are core >> specific to using the existing ImplicitPlugins.json file for >> configuration. This would centralize a bit where we create our defaults. >> > > RE 1 & 2: Why separate some from others? Assuming we desire this > separation, I don't think "ADMIN" would be the distinguishing word... more > like "BUILTIN". > > I'm surprised that response writers even exist at a SolrCore level. I've > known this but have felt it makes no sense. They are consulted at > HttpSolrCall level (above individual cores). I see it as very awkward how > it reaches into the core to get one, and has to make special accomodations > for admin/internal situations. To me, they should be node level plugins, > not changeable/configurable at core/configset level. The current situation > is probably an accident of history, one that wasn't thought through. IMO > registering/customizing them should be in solr.xml. > > >> 3) Add support for a configset level "ImplicitPlugins.json" file that if >> it exists is used instead of the global "ImplicitPlugins.json", which would >> allow me to remove the CSV related handlers and query response type. >> > > +1 (naturally; my idea). Albeit the name/format/existence of this file is > something I'd like to be deemed as "experimental" / subject to change. > > 4) Enhance configoverlay.json to allow you to delete any request handlers >> or request writers and track that deleted status in the configoverlay.json >> file, which would offer up a full lifecycle via the config API. > > > Ehhh, -1 veto; because it appears needless given a user-definable > ImplicitPlugins.json. I think it's simpler to code/maintain/document that > you can only delete a plugin that you register with that API. AFAIK that's > how it works now but correct me if I'm wrong. > >
