Storing persistent data

[andiempett]

Currently in Galicaster to store data persistently you must write it to areas of the disk generally in the mediapackage.
Galicaster does not have a dedicated method to store new data persistently between restarts.
storing the mediapackage on disk in an 'archive' make sense but again, extra parameters that are not part of the mediapackage, storing them in the mediapackage doesn't seem right.
a good example would be if you wrote a plugin that wanted to store some extra data specific to the plugin between restarts, holding it in ram would mean you would loose this data.

@ppettit suggested using SQL or something like this, maybe there is a nice 'pythonic' approach?

[ppettit]

What sort of data are you thinking of?

I am particularly keen to stop galicaster writing state into the config file, as we manage that using puppet and the application user account should not be writing into /etc

[andiempett]

Yeah this is probably a discussion. We would have to be clear what is stored where

I think the mediapackage should stay on disk and pretty much everything else should be put somewhere else

[paulgration]

What was the use case you had in mind @androidwiltron?

I'm wondering what kind of state information currently gets written back to the configuration file (apart from the profile)?

[andiempett]

Yeah so to be clear, keeping the config file would be sensible
I was thinking about data like extra metadata or parameters that we pass contextually to opencast. A good example is user IDs from log ins
The config file should be for static things
For data that changes it should either be in the mediapackage or if it's not part of the mediapackage, it should be elsewhere that is read/write

These are just ideas

[paulgration]

Yea I was pursuing the idea of mediapackage specific workflow-parameters from a plugin but it could still exist in the conf.ini as default-workflow-parameters allowing an override elsewhere maybe..

There's the galicaster.xml per mediapackage that is used for some things like this (now galicaster.json on the master branch), could that be used?