We should have a part of the file system dedicated to persistent data for extensions, such as configuration, logs, icons/logos, readme, and relevant user data.
Having a folder per extension would allow consistent binding rules, monitoring (to ensure data usage remains within user-specified limits), and clearing (e.g. when uninstalling, or as a refresh), and a fixed location (and filename structure?) for logs would make them easier to access and manage.
I recommend adding a shortcut (like the existing ones in the file browser), with extensions as the main folder, then docker-image-name for the individual extensions, which should include a logs folder for any logs, a readme file, an icon image file, a logos folder for company logos and the like (in case the user wants to include them in the upcoming logos section of the BlueOS interface), and anything else the extension wants to store.
Relevant to:
EDIT: We ended up deciding the directory structure of the binding should be /usr/blueos/extensions/<extension_name>/.
We should have a part of the file system dedicated to persistent data for extensions, such as configuration, logs, icons/logos, readme, and relevant user data.
Having a folder per extension would allow consistent binding rules, monitoring (to ensure data usage remains within user-specified limits), and clearing (e.g. when uninstalling, or as a refresh), and a fixed location (and filename structure?) for logs would make them easier to access and manage.
I recommend adding a shortcut (like the existing ones in the file browser), with
extensionsas the main folder, thendocker-image-namefor the individual extensions, which should include alogsfolder for any logs, a readme file, an icon image file, alogosfolder for company logos and the like (in case the user wants to include them in the upcoming logos section of the BlueOS interface), and anything else the extension wants to store.Relevant to:
EDIT: We ended up deciding the directory structure of the binding should be
/usr/blueos/extensions/<extension_name>/.