...

Modules can choose to implement this system multiple interface "configuration"

• GET /configurations/entries
• GET /configurations/entries/<id>
• POST /configurations/entries
• PUT /configurations/entries/<id>
• DELETE /configurations/entries/<id>

...

Here's where it might make sense to pull in additional technologies that are better suited to these requirements.  See the Technologies section below.  Having a module that presents a common interface in front of these technologies which is used internally (i.e. intended to be called only by other modules, not directly by clients) is an option that provides flexibility and opens the door to many potential benefits.

...

• Implements the configuration interface, or something that looks very similar.
• Uses a java interface to allow developers to add support for various underlying storage technologies - Maybe the default is just postgresql?
• Could enable multiple storage technologies, and the ability for the client to specify which storage they want to use...
  • This should be implemented via something like attributes so that the client doesn't need to know which storage technologies are available... just that there's one that has the attributes it cares ableabout.
    • For instance - store this thing somewhere that's "secure".  The module then looks for a configured storage that has the "secure" attribute, and stores it there. 
    • We'd have to allow for the administrator/operator to specify an order of precedence to help the module choose the right one in some cases.

...

• Migration of config data would need to be done on a per-module basis.  We could effectively deprecate mod-configuration and then at some later date retire/end-of-life it entirely.

JIRA

• Jira Legacy
  server FOLIO Issue TrackerSystem Jira serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key FOLIO-2583