Skip to main content
added 3 characters in body
Source Link

I have worked for a long time with asome well-known software which has its configuration files written in TCL, so the idea is not new. This worked quite well, since users who didn't know the language could still write/edit simple configuration files using a single set name value statement, while more advanced users and developers could pull sophisticated tricks with this.

I don't think that "the config files can get difficult to debug" is a valid concern. As long as your application doesn't force users to write scripts, your users can always use simple assignments in their configuration files, which is hardly any more difficult to get right compared to JSON or XML.

Rewriting the config is a problem, though it's not as bad as it seems. Updating arbitrary code is impossible, but loading config from a file, altering it and saving it back is. Basically, if you do some scripting in a config file which is not read-only, you'll just end up with an equivalent list of set name value statements once it is saved. A good hint that this will happen is a "do not edit" comment at the beginning of the file.

One thing to consider is that your config files won't be reliably readable by simple regex-based tools, such as sed, but as far as I understand this is already not the case with your current JSON files, so there's not much to lose.

Just make sure you use appropriate sandboxing techniques when executing your config files.

I have worked for a long time with a well-known software which has its configuration files written in TCL, so the idea is not new. This worked quite well, since users who didn't know the language could still write/edit simple configuration files using a single set name value statement, while more advanced users and developers could pull sophisticated tricks with this.

I don't think that "the config files can get difficult to debug" is a valid concern. As long as your application doesn't force users to write scripts, your users can always use simple assignments in their configuration files, which is hardly any more difficult to get right compared to JSON or XML.

Rewriting the config is a problem, though it's not as bad as it seems. Updating arbitrary code is impossible, but loading config from a file, altering it and saving it back is. Basically, if you do some scripting in a config file which is not read-only, you'll just end up with an equivalent list of set name value statements once it is saved. A good hint that this will happen is a "do not edit" comment at the beginning of the file.

One thing to consider is that your config files won't be reliably readable by simple regex-based tools, such as sed, but as far as I understand this is already not the case with your current JSON files, so there's not much to lose.

Just make sure you use appropriate sandboxing techniques when executing your config files.

I have worked for a long time with some well-known software which has its configuration files written in TCL, so the idea is not new. This worked quite well, since users who didn't know the language could still write/edit simple configuration files using a single set name value statement, while more advanced users and developers could pull sophisticated tricks with this.

I don't think that "the config files can get difficult to debug" is a valid concern. As long as your application doesn't force users to write scripts, your users can always use simple assignments in their configuration files, which is hardly any more difficult to get right compared to JSON or XML.

Rewriting the config is a problem, though it's not as bad as it seems. Updating arbitrary code is impossible, but loading config from a file, altering it and saving it back is. Basically, if you do some scripting in a config file which is not read-only, you'll just end up with an equivalent list of set name value statements once it is saved. A good hint that this will happen is a "do not edit" comment at the beginning of the file.

One thing to consider is that your config files won't be reliably readable by simple regex-based tools, such as sed, but as far as I understand this is already not the case with your current JSON files, so there's not much to lose.

Just make sure you use appropriate sandboxing techniques when executing your config files.

added 440 characters in body
Source Link

I have worked for a long time with a well-known software which has its configuration files written in TCL, so the idea is not new. This worked quite well, since users who didn't know the language could still write/edit simple configuration files using a single set name value statement, while more advanced users and developers could pull sophisticated tricks with this.

I don't think that "the config files can get difficult to debug" is a valid concern. As long as your application doesn't force users to write scripts, your users can always use simple assignments in their configuration files, which is hardly any more difficult to get right compared to JSON or XML.

Rewriting the config is a problem, though it's not as bad as it seems. Updating arbitrary code is impossible, but loading config from a file, altering it and saving it back is. Basically, if you do some scripting in a config file which is not read-only, you'll just end up with an equivalent list of set name value statements once it is saved. A good hint that this will happen is a "do not edit" comment at the beginning of the file.

One thing to consider is that your config files won't be reliably readable by simple regex-based tools, such as sed, but as far as I understand this is already not the case with your current JSON files, so there's not much to lose.

Just make sure you use appropriate sandboxing techniques when executing your config files.

I have worked for a long time with a well-known software which has its configuration files written in TCL, so the idea is not new. This worked quite well, since users who didn't know the language could still write/edit simple configuration files using a single set name value statement, while more advanced users and developers could pull sophisticated tricks with this.

I don't think that "the config files can get difficult to debug" is a valid concern. As long as your application doesn't force users to write scripts, your users can always use simple assignments in their configuration files, which is hardly any more difficult to get right compared to JSON or XML.

One thing to consider is that your config files won't be reliably readable by simple regex-based tools, such as sed, but as far as I understand this is already not the case with your current JSON files, so there's not much to lose.

Just make sure you use appropriate sandboxing techniques when executing your config files.

I have worked for a long time with a well-known software which has its configuration files written in TCL, so the idea is not new. This worked quite well, since users who didn't know the language could still write/edit simple configuration files using a single set name value statement, while more advanced users and developers could pull sophisticated tricks with this.

I don't think that "the config files can get difficult to debug" is a valid concern. As long as your application doesn't force users to write scripts, your users can always use simple assignments in their configuration files, which is hardly any more difficult to get right compared to JSON or XML.

Rewriting the config is a problem, though it's not as bad as it seems. Updating arbitrary code is impossible, but loading config from a file, altering it and saving it back is. Basically, if you do some scripting in a config file which is not read-only, you'll just end up with an equivalent list of set name value statements once it is saved. A good hint that this will happen is a "do not edit" comment at the beginning of the file.

One thing to consider is that your config files won't be reliably readable by simple regex-based tools, such as sed, but as far as I understand this is already not the case with your current JSON files, so there's not much to lose.

Just make sure you use appropriate sandboxing techniques when executing your config files.

Source Link

I have worked for a long time with a well-known software which has its configuration files written in TCL, so the idea is not new. This worked quite well, since users who didn't know the language could still write/edit simple configuration files using a single set name value statement, while more advanced users and developers could pull sophisticated tricks with this.

I don't think that "the config files can get difficult to debug" is a valid concern. As long as your application doesn't force users to write scripts, your users can always use simple assignments in their configuration files, which is hardly any more difficult to get right compared to JSON or XML.

One thing to consider is that your config files won't be reliably readable by simple regex-based tools, such as sed, but as far as I understand this is already not the case with your current JSON files, so there's not much to lose.

Just make sure you use appropriate sandboxing techniques when executing your config files.