qhana_plugin_runner
v1

Contents:

  • A Runner for QHAna Plugins
  • Writing Plugins
  • Writing Tests
  • Advanced Plugin Techniques
  • Special Plugin-Types
  • Data Formats defined for QHAna Plugins
  • Cli Documentation of the Flask app
  • All Plugins
  • Architectural Decision Log
    • 1. Template
    • 2. Use Markdown Architectural Decision Records
    • 3. Plugin Runner as Seperate Project
    • 4. Use Python
    • 5. Use Flask Template
    • 6. Use Celery Task Queue
    • 7. Plugins Must Provide Metadata
    • 8. Use MICRO-Frontends to Expose Algorithm Parameters
    • 9. Always Pass Files as URLs
    • 10. Complex Plugin Interactions
    • 11. Preprocessing Metadata to Apply the Same Processing to New Data [undecided]
    • 12. Repeating Steps in Multi-Step Plugins [undecided]
    • 13. Specify Additional Endpoints to used by Other Plugins
    • 14. Add a recipe data type [undecided]
    • 15. Subscribing for plugin updates
    • 16. Data inputs in substeps
    • 17. Schema links
      • 17.1. Context and Problem Statement
      • 17.2. Decision Drivers
      • 17.3. Considered Options
      • 17.4. Decision Outcome
      • 17.5. Pros and Cons of the Options
        • 17.5.1. Add a third link keyword for links to schemas
    • 18. Celery Task Testing Strategy
    • 19. Co-locate plugin tests with plugin code
    • 20. Pipeline adaptation for comparing hierarchical Subparts (Muse4Music)
    • 21. Pipeline adaption for non-tree taxonomies
  • qhana_plugin_runner package
  • Changelog
qhana_plugin_runner
  • Architectural Decision Log
  • 17. Schema links
  • View page source

17. Schema links

  • Status: [accepted]

  • Deciders: [Fabian Bühler]

  • Date: [2024-03-07]

17.1. Context and Problem Statement

Plugins can communicate their data inputs via their metadata. However, any other input currently relies on either the user correctly reading the microfrontend, special restrictions for certain plugin types (i.e. circuit executor plugins), or out of band information in the form of the OpenAPI specification served by the plugin runner.

How can we provide information about non data inputs in the plugin metadata?

17.2. Decision Drivers 

  • Do not break compatibility too much

  • Allow for automation

17.3. Considered Options

  • Add a third link keyword for links to schemas

17.4. Decision Outcome

Chosen option: “Add a third link keyword for links to schemas”, because it only requires small changes to the metadata and is entirely optional.

17.5. Pros and Cons of the Options

17.5.1. Add a third link keyword for links to schemas

Currently the plugin metadata and results can contain links using href for the REST endpoint and uiHref for micro frontends. In all places where these fields are used, we can add an optional third field schema to link to a schema that describes the inputs for the REST endpoint.

  • Good, because it requires only minimal additions to the current metadata

  • Good, because it allows for automatic discoverability of the inputs for REST endpoints without using the micro frontend

  • Bad, because it may require changes in tools consuming the plugin metadata

  • Bad, because the usefulness may not be immediate

Previous Next

© Copyright 2021, QHAna authors.

Built with Sphinx using a theme provided by Read the Docs.