Introduce a data model for "proctoring artifacts", aka the pictures and audios, which so far have only lived as files in the filesystem named after a convention
The new datamodel allows to quickly and reliably retrieve the pictures collected by proctoring and also provides for a technical space, in form of a JSON metadata column, to store additional information coming from e.g. postprocessing phases.
The idea is to use this feature to provide reviewing tools of proctoring results and allow for flexile downstream postprocessing.
The file naming convention has not been changed for the time being, so this would be retro-compatible. However, integrators should start relying on the new data model to retrieve pictures.
so far, to proctor applications that do not have a "single point of entry", such as e.g. dotlrn communities, we have integrated the lib/proctoring-enforce include into the website master template. Now we improve from this by introducing a callback mechanism that allows the single packages to decide if a request is "theirs to be proctored" or not.