I was re-reading this thread in preparation to review the PR David mentioned above, and had an interesting thought that hadn't struck me on previous readings. I hate to bring in new ideas at the "11th hour", but I'd also hate to leave it unsaid in case folks think there's something there. So, with my apologies, here goes. Feel free to ignore:
> 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! ... > "HttpSolrClient" (a great-name) ... > the desirable class name "HttpSolrClient" HttpSolrClient is a much better name to expose to folks than many of the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which I think is mostly what David was trying to convey in those quotes above. But is it *really* desirable in a general sense? The "Http-" prefix was (AFAICT) chosen at a time when it was necessary to distinguish these clients from "EmbeddedSolrServer" (which relied on a local SolrCore and didn't send any network traffic). But 10+ years on from that decision the "Http" signifier makes much less sense IMO. Today, the common-thread running through our "Http" SolrClients is that (1) they use a single base URL and (2) don't layer on any of the additional logic found in other implementations. At best, the "Http" signifier is disconnected from that commonality and does nothing to convey it. At worst, it's actively misleading: "Oh, I guess these are the only clients that use HTTP then", "Oh, I guess it only supports HTTP and not HTTPS" It'd be a bigger departure, but while we're renaming the clients is it worth considering something without the "Http" prefix altogether? Say, "SingleUrlSolrClient" or "SimpleSolrClient" or something along those lines? Apologies again for bringing this up, and so late at that. Best, Jason On Sun, Nov 2, 2025 at 4:39 PM David Smiley <[email protected]> wrote: > > Some progress: https://github.com/apache/solr/pull/3829 > > I think the org.apache.solr.client.solrj package should be used for not > only SolrClient (it's there now) but for HttpSolrClient (now that it's > abstract & simple), but also CloudSolrClient. It's debatable what belongs > in "impl"; I don't love that package name TBH. But the classes > in org.apache.solr.client.solrj should be chosen conservatively since we > have a rich set of sub-packages to organize most things. Thus *only* the > most foundational things that otherwise have no obvious home belong in > org.apache.solr.client.solrj. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
