> I'm lukewarm with "SimpleSolrClient" Fair enough - it's just there by way of example. If we agreed that the "Http"-prefix was worth reconsidering, I'm sure the group could arrive at *something* we like better.
> I think HttpSolrClient is a fine name too, I guess that's where I'm lost. What do you like about the prefix? Are there benefits or things you like about it beyond the fact that it has inertia? To my mind it conveys 0 bits of information. But maybe I'm missing something... On Thu, Nov 6, 2025 at 1:59 PM David Smiley <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
