I'm lukewarm with "SimpleSolrClient". I like that it conveys no additional value-add like SolrCloud awareness or load-balancing. However the JDK & Jetty impls have some sophistication to their implementations, like async. I think HttpSolrClient is a fine name too, plus users and LLMs have already become quite aware of it ;-). I don't think it implies a lack of SSL support.
My only concern with bringing HttpSolrClient back (or adding SimpleSolrClient) is that it doesn't _really_ need to exist as a base abstraction. In my PR, it just exposes a URL getter. So what; the caller probably should have no need to call that any way. It can be nice in a test that wants to manually then use an HttpClient, but it could just as well have gotten that URL from Jetty test infra. On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <[email protected]> wrote: > 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] > >
