This is some great perspective, and I love you caught the two ways I wrote it. I do the same with ConfigSets etc….
Plus, we have configoverlay.json out there that is slightly different. Is there a common pattern, like config-overlay.json and request-parameters.json or even request-parameter-sets.json that would make most sense? Wonder what other config files are hanging out there that have different naming schemes? As for the 404, not sure what the best approach is, however I think it’s better to focus on improving things, and not let that issue prevent us from improving the ref guide…. Plus, DuckDuckGo at least typically has a version number in the url…. I’m still clicking on Solr 6 links when I google “collection api solr ref guide” ;-) > On Feb 9, 2021, at 10:03 AM, Cassandra Targett <casstarg...@gmail.com> wrote: > > I have a slightly different view - the thing that creates a paramset, stored > in a file called params.json, is called the Request Params API, primarily > driven by RequestParams.java, which is why the page is called that. The > discrepancy between the naming of the API and the thing it creates has caused > this confusion. > > The name of the API is in fact more precise than the thing it creates - it’s > for request parameters, not other general parameters found in other contexts > - while the thing it creates is a shorthand name. > > All that’s not to say I object to the change. Just that it wasn’t done the > way it is without some thought having gone into it. I honestly just wish the > thing “paramsets” was called something else. > > (I frankly loathe the tendency to always shorthand “parameters” as “params” > in documentation. I’m the one who changed it from being the Request Params > API to the Request Parameters API and otherwise did the best I could with the > fact that the file is named “params.json” and not “request-params.json” or > something similarly more precise to its functionality.) > > A few things: > > While we’re changing things, is a code change warranted to make the name of > the thing “paramsets" more clear in terms of scope? Just throwing it out > there. > > Usually we don’t just rename pages entirely - there is no 404 redirect > mechanism currently in place, so users who may have figured out that the > Request Parameters API page = paramsets (as functionality) would find a 404 > in the docs from 8.9 forward. Do we care? (At the same time, though, we’re > going to need to address this eventually as I have a long list of page > renames coming for 9.0.) > > Settle on “paramSets” or “paramsets” or “ParamSets” - you used it 2 different > ways in your mail alone. It should be one way always. > On Feb 8, 2021, 12:02 PM -0600, Erik Hatcher <erik.hatc...@gmail.com>, wrote: >> >> >>> On Feb 6, 2021, at 9:48 AM, Eric Pugh <ep...@opensourceconnections.com> >>> wrote: >>> >>> “paramsets”, which I think is a really powerful feature that most people >>> don’t know about. >> >> Agreed on that! (see the old example/files for my early paramset usage as I >> explored that cool capability) >> >>> I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, >>> and rewrite the page to highlight that this feature is called “paramset”, >>> in the same way we use the term “configset”. >> >> +1 >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> _______________________ 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.
