These are all things that are required for the proper first release.

Edit: writing here in prose to formulate what is missing until we reach version 1.0.0. This can still be restructured into issues. Even if this comes a little late I hope it will help to better align efforts until we reach a version that we can show to externals. This will rather be user stories than pure backend related topics but I see the backend as the place where it all comes together.

Version 1.0.0:

• streams waveforms upon opening a sensor waveform view to the front-end for remote quality control

• Allows the user to check uptime, chrony parameters. issue https://git.quakesaver.net/QuakeSaver/frontends-next/-/issues/15 ?

• Allows users to download waveform data given the respective access rights via fdsn (limited to what is available in the sensors ring buffer) depends on https://git.quakesaver.net/QuakeSaver/sensor/ringnes/-/issues/293

• Allows users to modify (remotely):

  • sampling rate

• Allows to exchange databases to persist data later (1D, 2D, binary, given technical limitations such as binary + influx doesn't work). If exchanging databases already is foreseeable to be a huge road block the architecture should be revisited. We had repeated long discussions debating if influx or monogdb is the right techincal choice. We came to a basic conclusion that:

  • any 1D data -> influxdb
  • binary (and 2D in the future(!)) -> mongodb

  However, the final storage architecture is not there yet and there will be questions coming up which may prove this approach wrong. So, just make sure the technical debt doesn't strike back when we have to change the strategy. -> depends on https://git.quakesaver.net/QuakeSaver/server/qs-server/-/issues/51

• user account handling for admins

• start page content

• remove unused content for 1.0.0 release in frontend

• high level API tests (fastapi tests)

Briefly wrapping up our discussion today (20.5.2022):

• We steer towards alternatives to JSON for transmitting data (e.g. BSON) (rather Milestone 1.1.0?)
• Data payloads inherting from class Metric (or class Scalar? / 0-dimensional) values base classes -> InfluxDB c.f. https://git.quakesaver.net/QuakeSaver/server/qs-server/-/issues/51
• Any data payload that is not inherting from class Metric is inherting from class Dataproduct (e.g. higher dimensional data, binary)
• Payloads will not be validated upon ingestion. Instead, data regularization and validation will be done (in the future, thus not v1.0) by a service upon receiving a request. Thus, avoids data migration of data contained in the database (at the cost of having a migration chain that migrates data on the fly on each request).