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]
