This is an unconfirmed road map for Qvarn software development. We currently do not have an order or target dates, as developent progresses based on paying customer demand.

Things for which deadlines have not been set yet

  • Make resource types be configurable via the Qvarn API.

    • Justification:
      • Currently any changes to the supported resource types requires changing Qvarn source code and making a new Qvarn release. This is untenable with many users.
      • Currently Qvarn developers are on the critical path for most Qvarn-using projects, and are often needed for consultation for any resource changes. This takes up too much time from them and is too much of a blocker for others.
    • Success criteria:
      • A freshly installed Qvarn has a minimal set of resource types.
      • New resource types can be added, and existing ones can be changed and deleted via the Qvarn API.
      • Changes to resource types happen immediately: it's not OK to have to restart Qvarn, and it must not be necessary to reconfigure haproxy to implement them.
      • All existing resource types must be implementable with the new way, excluding validation code.
      • Validation code will no longer be supported.
  • An automated performance test suite, run regularly by CI, with measurements to identify critical bottlenecks.

  • Support virtual cards.

    • Tie an "electronic card" (app on a smartphone, Yubikey, or similar) to a physical ID card.
  • Support consent management, UMA: subjects need to give explicit consent to every type of use of their data.

  • Add API call to get complete and corresponding source code.

  • Support resource version history via the Qvarn API.

  • Support water stamping, digital signing of data Qvarn returns.

  • Add sensible blob storage to Qvarn.

  • Encryption of the database (store database on an encrypted disk).

  • Fix the SPOF and bottleneck of the write-only node in Qvarn.