You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Jan Høydahl <ja...@cominvent.com> on 2023/02/16 14:42:07 UTC
[DISCUSS] Rebrand the JSON Request/Facet APIs
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
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Houston Putman <ho...@apache.org>.
>
> 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'...
JSON Request DSL (or just JSON Request Language) is perfectly fine with me.
And once we get other initiatives out of the way, it would be great to see
Solr move more towards this. Other platforms (elastic, opensearch, mongo,
etc) have seen a lot of success here, and I think our old style syntax kind
of pushes new people away.
Obviously this is a separate (but related) topic on this thread, but I like
the name at least.
- Houston
On Tue, Apr 4, 2023 at 8:20 AM Jan Høydahl <ja...@cominvent.com> wrote:
> 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 <
> ichattopadhyaya@gmail.com>:
> >
> > +1 to "Aggregation API"!
> >
> > On Fri, 10 Mar 2023 at 21:02, Michael Gibney <mi...@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 <ja...@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 <
> >> epugh@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 <ds...@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 <
> >>>>>> ichattopadhyaya@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.benedetti@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.benedetti@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 <ds...@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 <
> >> houston@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.asf@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-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Ere Maijala <er...@helsinki.fi>.
Hi,
Please bear with me if I'm completely lost in the forest. I don't have
much experience with what's currently called "JSON Request API" or "JSON
Facet API" as I'm mostly working on software that uses the (legacy
legacy?) GET request query string API. Which brings me to the point I'd
like to make.
Before any JSON API came to exist, there was just the one I still use.
And it was simple to use for simple things, such as writing a quick
query. And then when you realized you needed facets, you just added the
settings to the query. The tutorials and most of the Query Guide reflect
this, and hardly mention on any of the pages that the parameters
described are put in the query string.
But then the JSON Request API is a sub-page of Query Guide, and things
become confusing. It's not the same, and parameters described on other
pages are not the same. But you can still use it for searching and
faceting. But then there's the JSON Facet API, and the relation between
that and the JSON Request API seems obvious but isn't quite clear.
So whatever the results of this discussion are, I think they should be
reflected clearly in the documentation, preferable including any upsides
and downsides compared to other methods, and any relationship they may
have. An unambiguous name is important, but so is documentation. And the
definition of an API. To me the JSON Facet API looks more like a very
flexible and useful extension to the original query string API and not
really a full API, but it's quite possibly just me picking nits.
And then one thing about naming in general: calling anything "the legacy
one" or "the new one" becomes a bit problematic when the next version
after "the new one" is introduced. :)
Best,
Ere
Jan Høydahl kirjoitti 4.4.2023 klo 15.20:
> 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 <ic...@gmail.com>:
>>
>> +1 to "Aggregation API"!
>>
>> On Fri, 10 Mar 2023 at 21:02, Michael Gibney <mi...@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 <ja...@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 <
>>> epugh@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 <ds...@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 <
>>>>>>> ichattopadhyaya@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.benedetti@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.benedetti@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 <ds...@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 <
>>> houston@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.asf@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-unsubscribe@solr.apache.org
>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
--
Ere Maijala
Kansalliskirjasto / The National Library of Finland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <ic...@gmail.com>:
>
> +1 to "Aggregation API"!
>
> On Fri, 10 Mar 2023 at 21:02, Michael Gibney <mi...@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 <ja...@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 <
>> epugh@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 <ds...@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 <
>>>>>> ichattopadhyaya@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.benedetti@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.benedetti@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 <ds...@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 <
>> houston@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.asf@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-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
+1 to "Aggregation API"!
On Fri, 10 Mar 2023 at 21:02, Michael Gibney <mi...@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 <ja...@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 <
> epugh@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 <ds...@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 <
> > >>> ichattopadhyaya@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.benedetti@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.benedetti@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 <ds...@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 <
> houston@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.asf@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-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Michael Gibney <mi...@michaelgibney.net>.
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 <ja...@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 <ds...@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 <
> >>> ichattopadhyaya@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....@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.benedetti@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 <ds...@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 <ho...@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 <ja...@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-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <ds...@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 <
>>> ichattopadhyaya@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....@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.benedetti@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 <ds...@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 <ho...@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 <ja...@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-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by 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 <ds...@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 <
> ichattopadhyaya@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....@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.benedetti@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 <ds...@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 <ho...@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 <ja...@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.
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by David Smiley <ds...@apache.org>.
+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 <
ichattopadhyaya@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....@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.benedetti@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 <ds...@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 <ho...@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 <ja...@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
> > > >
> > >
> >
>
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Mikhail Khludnev <mk...@apache.org>.
Hello,
Naming is not my favorite thing to do at all.
But, if I check the guide I have:
complex or nested facets
Checking thesaurus gives me:
grained, ingrained, deep,dwelt, dwelled, tree-ish, branched, flexible
composite, compound, multiplex (multifacets? ), tangled, combined.
Does anything of this thesaurus resonate with someone?
On Fri, Feb 17, 2023 at 1:37 PM Ishan Chattopadhyaya <
ichattopadhyaya@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....@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.benedetti@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 <ds...@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 <ho...@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 <ja...@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
> > > >
> > >
> >
>
--
Sincerely yours
Mikhail Khludnev
https://t.me/MUST_SEARCH
A caveat: Cyrillic!
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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....@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.benedetti@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 <ds...@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 <ho...@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 <ja...@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
> > >
> >
>
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Alessandro Benedetti <a....@sease.io>.
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.benedetti@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 <ds...@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 <ho...@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 <ja...@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
> >
>
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by David Smiley <ds...@apache.org>.
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 <ho...@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 <ja...@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
>
Re: [DISCUSS] Rebrand the JSON Request/Facet APIs
Posted by Houston Putman <ho...@apache.org>.
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 <ja...@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