Trying to sum up this discussion. I agree that V2-facet-api is not so good a name after all.
So we basically have two main suggestions in this thread then: A) "The Faceting API" and then the need to re-brand "The legacy Faceting API" B) "The Aggregation API" vs whatever we called it before Do anyone else want to weigh in your preference on these two? If we're going to push for the JSON-style request DSL as well, do we need to come up with a shiny new name for that as well, or will JSON Request DSL work? It's basically a HTTP post with JSON instead of 'application/x-www-form-urlencoded'... Jan > 13. mar. 2023 kl. 20:21 skrev Ishan Chattopadhyaya > <ichattopadhy...@gmail.com>: > > +1 to "Aggregation API"! > > On Fri, 10 Mar 2023 at 21:02, Michael Gibney <mich...@michaelgibney.net> > wrote: > >> I kind of like "Aggregation API" (or something similar). >> Facets/stats/analytics are all definitely "aggregations". As luck >> would have it, "aggregation" isn't yet used to mean something more >> specific in Solr (right?), so we wouldn't have the problem of "it used >> to mean X, but now it means Y". The term has the benefit of being both >> accurate (semantically sound) and also corresponds to how analogous >> functionality is named in comparable products. Regarding simply >> calling it *THE* Faceting API -- I'm afraid in practice that >> distinction would be lost on many users. Also, current "JSON Facet" >> supports aggregate functions etc... are these really best described as >> "facet functions" as opposed to "aggregations"? >> >> From my perspective +1 on "v2" being overloaded (or maybe "overloaded" >> is not quite the right word?). And even if v2/v3/etc. is used to >> describe the API, we still need a name to differentiate >> aggregation-type functionality from search functionality. In order to >> be able to refer to the replacement for facet/stat/analytics, we'd >> need to refer to, e.g.: "the Aggregations API, introduced in v3, >> descended from JSON facet API, and providing functionality to replace >> legacy facets, stats, and analytics". >> >> Part of what makes "v2" etc. awkward, for faceting in particular, is >> that "v1" was ... what, exactly? Legacy FacetComponent isn't really a >> self-contained API, it's kind of just a bunch of thematically related >> top-level request parameters. If someone informally asked me what "v2" >> meant in Solr, tbh I'd probably say ... "oh, that's if you use JSON" >> :-) >> >> IMO (similar to what Mikhail was saying iiuc) the key distinction >> between and "legacy"/"classic" FacetComponent and the JSON facet API >> is that the latter natively/idiomatically supports hierarchical >> configurations and aggregate functions. >> >> It would be great to have the admin UI guide users towards the new >> API. The strong point of the new API(s) is their hierarchical/nested >> aspect, which unfortunately calls for a more complex admin UI design >> -- "auto completing JSON editor" as Jan suggests, or even a nested >> form-based UI "client" that doesn't force people to manually fuss with >> JSON. >> >> On Sat, Feb 18, 2023 at 6:34 PM Jan Høydahl <jan....@cominvent.com> wrote: >>> >>> Would be cool if the admin ui query screen had a feature for showing the >> JSON equivalent of current ui input fields. And of course a brand new auto >> completing JSON editor for the new syntax! >>> >>> Jan Høydahl >>> >>>> 18. feb. 2023 kl. 14:11 skrev Eric Pugh < >> ep...@opensourceconnections.com>: >>>> >>>> Change the Admin UI to support the new syntax? So folks who are >> new to Solr learn the new way of doing things…. ?? >>>> >>>>> On Feb 17, 2023, at 3:46 PM, David Smiley <dsmi...@apache.org> wrote: >>>>> >>>>> +1 to Ishan's proposal. Make it *the* Faceting API, and rebrand the >> old >>>>> one to legacy or classic. The surface of the API might live on for >>>>> simple/trivial faceting; so maybe the word "classic" could be used if >> it >>>>> continues. >>>>> >>>>> ~ David Smiley >>>>> Apache Lucene/Solr Search Developer >>>>> http://www.linkedin.com/in/davidwsmiley >>>>> >>>>> >>>>>> On Fri, Feb 17, 2023 at 5:37 AM Ishan Chattopadhyaya < >>>>>> ichattopadhy...@gmail.com> wrote: >>>>>> >>>>>> I'd prefer the JSON faceting API to be called just Faceting API, and >> the >>>>>> other one as Legacy Faceting API (and deprecated). >>>>>> >>>>>> The moment we deprecate it, usecases will emerge where legacy >> faceting is >>>>>> faster or more functional, and we can work on supporting those going >>>>>> forward. >>>>>> >>>>>> In deprecated state, there could be warnings in the API response >> and/or >>>>>> logs indicating that this API is deprecated. >>>>>> >>>>>> On Fri, 17 Feb, 2023, 2:26 pm Alessandro Benedetti, < >> a.benede...@sease.io> >>>>>> wrote: >>>>>> >>>>>>> In general, I dislike the V2, V3, V<something> when rebranding a >> method >>>>>> or >>>>>>> a service as it doesn't add any semantic value to the name, on the >> other >>>>>>> hand, Json-API hints it has to do with JSON payloads. >>>>>>> >>>>>>> Given that, I am +1 in rebranding them, but I have no idea at the >> moment >>>>>>> for a better name than what it's currently in place ... >>>>>>> -------------------------- >>>>>>> *Alessandro Benedetti* >>>>>>> Director @ Sease Ltd. >>>>>>> *Apache Lucene/Solr Committer* >>>>>>> *Apache Solr PMC Member* >>>>>>> >>>>>>> e-mail: a.benede...@sease.io >>>>>>> >>>>>>> >>>>>>> *Sease* - Information Retrieval Applied >>>>>>> Consulting | Training | Open Source >>>>>>> >>>>>>> Website: Sease.io <http://sease.io/> >>>>>>> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter >>>>>>> <https://twitter.com/seaseltd> | Youtube >>>>>>> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github >>>>>>> <https://github.com/seaseltd> >>>>>>> >>>>>>> >>>>>>> On Fri, 17 Feb 2023 at 04:29, David Smiley <dsmi...@apache.org> >> wrote: >>>>>>> >>>>>>>> V2 shouldn't be overloaded then *that* is a problem. Can we just >> call >>>>>>> the >>>>>>>> new JAX-RS stuff V3 and then voila, we call this V3 faceting API? >>>>>>>> >>>>>>>> ~ David Smiley >>>>>>>> Apache Lucene/Solr Search Developer >>>>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 16, 2023 at 11:42 AM Houston Putman < >> hous...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks for bringing this up! >>>>>>>>> >>>>>>>>> I agree the name of the API is bad. The thing is it's not only >>>>>>> faceting, >>>>>>>>> it's also stats/analytics. >>>>>>>>> >>>>>>>>> Maybe the "aggregation API"? but I'm not sure that's any better... >>>>>>>>> >>>>>>>>> I do think "v2" is an already overloaded term that comes with a >> lot >>>>>> of >>>>>>>>> baggage, so I would personally vote we steer in a different >>>>>> direction. >>>>>>>>> >>>>>>>>> - Houston >>>>>>>>> >>>>>>>>> On Thu, Feb 16, 2023 at 9:42 AM Jan Høydahl < >> jan....@cominvent.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi devs, >>>>>>>>>> >>>>>>>>>> Although it's been nagging me for a while, today it hit me that >> the >>>>>>>> "JSON >>>>>>>>>> request API" has a terrible name. >>>>>>>>>> >>>>>>>>>> I hope to start a discussion on re-branding it and somehow pitch >> it >>>>>>> as >>>>>>>>> the >>>>>>>>>> (not-so-new) "V2" search / facet API. Good timing as part of the >>>>>>> other >>>>>>>> V2 >>>>>>>>>> efforts. >>>>>>>>>> That may in turn lead to increased usage and take the role as the >>>>>>>>>> "standard" search API instead of the "alternative". >>>>>>>>>> >>>>>>>>>> Of course I know that what we normally mean as "V2" API is the >>>>>> /api/ >>>>>>>> URL, >>>>>>>>>> not the syntax of the payload, i.e. you can do both old-style and >>>>>>>>>> JSON-style queries on both V1 adn V2 search endpoint. So I'm not >>>>>>> sold >>>>>>>> on >>>>>>>>>> "V2" being the perfect name here. But from a pure branding >>>>>>> perspective, >>>>>>>>>> signaling that it is the "new" way, perhaps it can fly? >>>>>>>>>> >>>>>>>>>> See JIRA https://issues.apache.org/jira/browse/SOLR-16663 for >> some >>>>>>>>>> initial thougts. Please keep the broader discussion here, and >> more >>>>>>>>>> implementation related input in JIRA. >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> _______________________ >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 >> | http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>> >>>> This e-mail and all contents, including attachments, is considered to >> be Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
