Those are some good names Jan. However, all clients can talk to any number of cores/collections merely by adding its name to an overloaded method (which I don't like BTW, alas), so that kind of rules out CoreSolrClient. And these clients can actually talk to whatever URL via requestWithBaseUrl.
I think I prefer to actually take no action here in the end. They don't need a base abstraction beyond SolrClient. On Thu, Nov 6, 2025 at 6:38 PM Jan Høydahl <[email protected]> wrote: > CoreSolrClient - Emphasizes it works with a single core/collection, and it > is also the core of the other clients > DirectSolrClient - Direct endpoint access > > Jan > > > > 6. nov. 2025 kl. 21:48 skrev David Smiley <[email protected]>: > > > > 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] > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
