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)
