[FEATURE] ODTP GUI setting for external ODTP zoos

[jugdemon]

• Feature name: Management of ODTP zoos

Description:

Currently, the ODTP zoo is hosted on odtp-org. In principle, we wanted to support multiple zoos. I am moving towards developing another zoo and it would be great if the ODTP GUI supports loading components from various zoos. Currently, the component list is empty without manually populating it. I would suggest that we can set zoos from which to load components. There should be a default (odtp-org/odtp-zoo) and the ability to add more zoos, remove zoos and set another or multiple defaults. It would be nice if this setting is exposed in the settings when installing ODTP so that users can immerse themselves immediately in components relevant to their work.

Importance Level

Medium

Managing the zoos will allow ODTP to grow sustainably as different user groups can specialise their component choices without getting overwhelmed.

Origin

I am currently developing animal digital twins ( https://github.com/iumenta ) and I would like to create a zoo for components there so that it doesn't mix with the mobility components we currently have. I also think that it might be nice to split our current ODTP components into generic processing components that stay in the ODTP zoo and mobility-based components that we move out of odtp-org into a separate org that manages a mobility zoo. This might also help with managing components as the responsibility will become more clear by organisation.

User Impact

Users from different backgrounds can install ODTP with a set of default components that fit their background.

Mockups or Diagrams

Visual representations (if applicable) to help clarify the feature or feedback. This could include UI mockups, flowcharts, or architectural diagrams.

Affected Components (examples: components, modules, … )

Identification of specific parts of the project that the feature or feedback pertains to. This could be ODTP modules or ODTP components.

This should affect odtp in its GUI and the installation.

Technical Requirements (if possible, otherwise completed by SDSC)

Detailed technical specifications or requirements needed to implement the feature. This could include algorithms, data structures, APIs, or third-party services.

Related Documents/Links:

References to any related documentation, user stories, tickets, or external resources that provide additional context.

Dependencies (if possible, otherwise completed by SDSC):

Identification of any other features, systems, or processes that the proposed feature depends on or interacts with. This can be considered a “ready if” field and it will define what’s needed to have in order to start the development.

Acceptance criteria:

Specific criteria or metrics for evaluating the success or effectiveness of the feature once implemented.