Let's remove it. Well, I mean, not add it back :-) On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <[email protected]> wrote:
> > 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] > >
