Current state: "Draft"
Discussion thread: https://lists.apache.org/thread/3qppq1nks6vwf6m5lljbw9nmofb90lbp
JIRA:
Released: <Solr Version>
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.
Solr's omnipresent NamedList (not SimpleOrderedMap) holds the project back from better JSON compatibility, and use of a standard Java Map abstraction. Why is this?:
(A) In response structures, switching a NamedList (even SimpleOrderedMap) to a MapWriter or Map breaks compatibility with SolrJ "javabin" consumer, which makes a distinction between NamedList and Maps. This compatibility break can be subtle, showing itself later. The type change can also cause the JSON response to change. While that may seem fair/expected, if we minimize NamedList usage then the problem is also minimized.
(B) A NamedList may hold repeated keys, and thus it can't be a Map (or be serialized to JSON) without a conversion that addresses key repetition somehow. Minimizing NamedList minimizes a conversion (faster). Solr serializes NamedLists to JSON using one of several strategies the user can choose with the "json.nl" parameter, which is awkward. Ideally, with less NamedList usage, this would be a rare thing so that Solr has a more consistent JSON API that doesn't flip-flop. There is also awkwardness in mapping JSON based configuration to a NamedList for the same underlying issues – repeated key handling.
Some important Solr APIs for both configuration and response processing specify a NamedList, and consequently the possibility of repeating keys. But the actual need for this is rare. For an API producing a response, it's too easy / obvious to supply a NamedList, even if keys don't repeat. For configuration, ideally Solr would prevent a likely mistake of repeating a key, assuming Solr is modified to disallow such for root configuration elements.
While there is a special and important subclass of NamedList named "SimpleOrderedMap", all references to NamedList here mean the implementing type NamedList and not SimpleOrderedMap.
Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.
The definition of a public interface is found on the main SIP page.
Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.
Describe in few sentences how the SIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.