Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support different modules per interface simultaneously #3154

Open
4 tasks
matthias-ronge opened this issue Feb 7, 2020 · 3 comments
Open
4 tasks

Support different modules per interface simultaneously #3154

matthias-ronge opened this issue Feb 7, 2020 · 3 comments
Labels

Comments

@matthias-ronge
Copy link
Collaborator

matthias-ronge commented Feb 7, 2020

Description

The Module Loader is currently programmed so that if there are several modules that offer an interface, it takes any of them. In principle, this can even change from one Tomcat start to the next.

The goal should be that several different modules for the same interface (e.g. several catalog modules) are operated in parallel and the user can select at a relevant point which module he or she wants to use.

TODO:

Part 1

  • adjust Service Loader to enable multiple modules
  • enable configuration to choose specific modules
  • move module source code in separate repositories to keep them independent (start with API)

Part 2

  • identify places, where user interaction is desired in frontend to select a specific module and implement selection

Estimated Costs and Complexity

Part 1

is a mid-ranged project with 6-7 PT

Part 2

is a mid-ranged project with 8-10 PT

@matthias-ronge matthias-ronge changed the title Revise module loader Support different modules per interface simultaneously Apr 8, 2020
@Kathrin-Huber Kathrin-Huber added the development fund 2021 A candidate for the Kitodo e.V. development fund. label Feb 18, 2021
@stefanCCS
Copy link
Collaborator

Sorry, but I do not really understand the purpose.
If this change would allow more/other features in the future, then please explain more detailed, what is about.
If it is "just" a software internal optimization, then please decide by your (dev team) own, if/when/how you would like to do this.

@matthias-ronge
Copy link
Collaborator Author

The reason Production was broken into modules is to allow for different modules. For example the Generator Interface: It should be possible to connect a URN generator as a module, and a PURL generator, and a process title generator, etc. Likewise, schema converter, if a new format is to be supported, a new schema converter is created for it. If two clients want to use two different data stores, two file management modules are used, one for example using the file system and the other using a repository. All of this presupposes that with several modules these can be used at the same time and that one that fits is not selected at random from several.

@stefanCCS
Copy link
Collaborator

Many thanks for sharing this details.
Now, at least I have an idea, and in general, this idea sounds very interesting.

@Kathrin-Huber Kathrin-Huber added the development fund 2022 A candidate for the Kitodo e.V. development fund. label Feb 21, 2022
@solth solth removed the 3.x label Jul 7, 2022
@matthias-ronge matthias-ronge added the development fund 2023 A candidate for the Kitodo e.V. development fund. label Feb 27, 2023
@solth solth removed development fund 2021 A candidate for the Kitodo e.V. development fund. development fund 2022 A candidate for the Kitodo e.V. development fund. development fund 2023 A candidate for the Kitodo e.V. development fund. labels Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants