The URL bit is referring to how you configure it to talk to solr. REST is a whole other thing (REpresentational State Transfer), and not really relevant to the java client which should communicate with whatever protocol is most efficient/convenient/debuggable/etc (json/javabin/xml/cbor/parameters/etc) regardless of how it's configured to talk to solr.
On Fri, Nov 7, 2025 at 12:24 PM Aditya Parikh <[email protected]> wrote: > SolrRestClient? > > Thanks, > Aditya > > > On Fri, Nov 7, 2025 at 10:32 AM Gus Heck <[email protected]> wrote: > > > I don't think the "single" is needed on SingleUrlSolrClient? URL is > > singular anyway > > > > On Fri, Nov 7, 2025 at 9:31 AM Jason Gerlowski <[email protected]> > > wrote: > > > > > Oh, I'm surprised - I wasn't really trying to comment on the existence > > > of a base abstraction (or not). In a way that's an independent > > > question from whether we want to keep the "Http"-prefix around. > > > > > > I really liked your PR #3829, fwiw. And even if we decide that > > > "Http-" should go away eventually, we needn't do that in this PR or > > > even for 10.0. It may make sense to wait before acting on > > > that...particularly if we don't have an alternative that we all love > > > yet (which seems to be the case). > > > > > > ---- > > > > > > I like "DirectSolrClient" from a naming perspective fwiw. IMO it does > > > a good job of signaling the low-level-ness of these clients: they're > > > "just" sending requests without any of the layered-on logic that our > > > other clients offer. > > > > > > I'd also make another pitch for "SingleUrlSolrClient". David's > > > reintroduction of "HttpSolrClient" in #3829 really highlights IMO that > > > the one thing all of these "Http-" clients have in common is their > > > single-URL-ness. ('getBaseUrl' is essentially the only method offered > > > in the "base abstraction" in that PR). Yes, "requestWithBaseUrl" > > > exists, but that's very much the "exception" rather than the normal > > > case. > > > > > > Best, > > > > > > Jason > > > > > > On Thu, Nov 6, 2025 at 9:32 PM David Smiley <[email protected]> > wrote: > > > > > > > > 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] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > > http://www.needhamsoftware.com (work) > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
