I like those name/renaming suggestions. I do think it introduces a bit of client-code churn for folks, but it's nothing unreasonable and I think the clarity that the improved names add would be worth it in the long run.
+1 On Sat, Sep 27, 2025 at 10:48 AM David Smiley <[email protected]> wrote: > > I've been thinking exactly this thing, and here you proposed it :-). I also > mentioned it to Jason at the hackathon. > > People expect to have an "HttpSolrClient" type; the recent Solr MCP was > using it -- perhaps written in part by an LLM that knows about > HttpSolrClient's pervasiveness. And who can blame any person or LLM for > using such an obvious name like that. What a great name! Our issue as a > project is the *implementation*. > > HTTP: > * HttpSolrClient base type; not much if any implementation > * HttpJettySolrClient (formerly known as Http2SolrClient) > * HttpApacheSolrClient (formerly HttpSolrClient). > * HttpJdkSolrClient (already named well). > > CLOUD: > * CloudSolrClient base type > * CloudJettySolrClient (from CloudHttp2SolrClient) > * CloudApacheSolrClient (currently CloudLegacySolrClient). One could argue > just leave it be given how soon it will be deleted > * (no JDK variant exists yet, sadly) > > LB: > (I dislike that the B is capitalized; would prefer to lowercase that) > * LBSolrClient base type > * LBJettySolrClient (from LBHttp2SolrClient) > * LBApacheSolrClient (from LBHttpSolrClient) > * (no JDK variant exists yet) > > CONCURRENT UPDATE > * NO ConcurrentUpdateSolrClient base abstraction needed? Or just add it > with nothing > * ConcurrentUpdateApacheSolrClient (from ConcurrentUpdateSolrClient) > * ConcurrentUpdateJettySolrClient (from ConcurrentUpdateHttp2SolrClient) > > Using a sequence of "git mv" operations on multiple commits, we could > retain source control history, even though the project wouldn't build at a > specific intermediary commit. > > All that would be Solr 10 only, but Solr 9 could un-deprecate > HttpSolrClient along with documentation explaining what's happening. > > Of course, all of this will be quite disruptive to anyone with WIP on these > very classes. James Dyer, I'm thinking of you. > > On Sat, Sep 27, 2025 at 7:57 AM David Eric Pugh <[email protected]> > wrote: > > > Looking at Http2SolrClient after talking to David S the other day, and boy > > is it confusing. I thought it was the "client that speaks Http 2", not > > "the second Http Client that speaks 1 and 2". > > We have a javadoc:* <p>Despite the name, this client supports HTTP 1.1 and > > 2 -- toggle with {@link > > * HttpSolrClientBuilderBase#useHttp1_1(boolean)}. In retrospect, the name > > should have been {@code > > * HttpJettySolrClient}.With Solr 10 coming up, should we have a > > HttpJettySolrClient that then is extended by Http2SolrClient and go ahead > > and deprecate Http2SolrClient? > > Or, just rip the bandaid off, and deprecate Http2SolrClient in 9x, and > > introduce HttpJettySolrClient in 10? I'm guessing usage of > > Http2SolrClient out in the wild isn't yet prevalent. > > Or neither... --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
