Design goals

It may make sense to have common understanding of what the package is supposed to be for, in order to derive design decisions from that. I am making a first draft, feel free to comment and we can update and expand the text in this comment. Some of these goals are conflicting, and we will have to find a trade-off.

Target use and audience:

• Serve as a library basis for simson development
• Serve as a library basis for other MFA's by external users.
  • Use cases and types of MFAs can be very diverse.
  • MFA users should not have to have a strong coding background to use this package.

This leads to the following design goals: The package should be...

• As flexible as possible, in how it can be used and what it can be used for.
• As easy as possible to use, which includes
  • having few lines of code for a baseline/default case
  • being able to use and to customize it without using complex coding patterns and tools. Example: It should be possible to input and output the data in whatever format, selection and combination people like.
  • The code being transparent about what it does, i.e. the lines written by the user hinting towards what's happening under the hood. Example: We should only require them to implement subclasses where it has substantial benefits to the rest of the code.
• The package itself should be extensible in the future. I'm sure the need to extend it will arise. Example: Data paths should be given as an argument, not be pre-defined in the code
• We should reduce package API changes to a minimum in the near future.
• Giving erroneous/unintended input should throw errors which make the problem clear to the user.
• Users should be able to fully learn how to use the package without looking at the source code, i.e. from documentation (Installation guide, API reference, examples)