What if consumers of the DSP only want to use it to build works based on it or a DSP developer wants to prevent unwanted modifications outside of a defined contribution workflow.
If the DSP were distributed via NPM, there's no direct means of updating/syncing the DSP back to a centralized source, so the VS Code extension would need to disable edit capabilities. However, if there are errors or modifications that can be made, there should be a way to guide the consumer toward an approved contribution workflow (e.g., GitHub, etc.).
Settings
What if there were a settings.readonly config that were optional?
{
"settings": {
"readonly": true
}
}
If settings.readonly isn't present it is assumed to be false and everything works as it currently does.
If settings.readonly === true, extensions/plugins/apps would disable modification of the DSP in-app on the consumer's machine.
What if consumers of the DSP only want to use it to build works based on it or a DSP developer wants to prevent unwanted modifications outside of a defined contribution workflow.
If the DSP were distributed via NPM, there's no direct means of updating/syncing the DSP back to a centralized source, so the VS Code extension would need to disable edit capabilities. However, if there are errors or modifications that can be made, there should be a way to guide the consumer toward an approved contribution workflow (e.g., GitHub, etc.).
Settings
What if there were a
settings.readonlyconfig that were optional?settings.readonlyisn't present it is assumed to befalseand everything works as it currently does.settings.readonly === true, extensions/plugins/apps would disable modification of the DSP in-app on the consumer's machine.