Interpreter configuration stored in INI file

belliash commented

2018-07-31 13:50:51 +02:00

Owner

I think, this is a good idea, to save Interpreter configuration in INI file, like it is done in PHP, thus giving end user more control over it. However, I was thinking about doing it in a bit another way.

[general]
some_option=1
another option=1

[sapi:cli]
some_option=0

[sapi:cgi]

[module:dummy]
dummy_specific=1

General idea, is to have single INI file for storing configuration. The general section would store all interpreter's configuration, however any of them could be overwritten by SAPI-specific option. Thanks to that, end user could quickly and easily configure it, and still have some flexibility. Real life example: in general section we allow to use exec-alike functions, but in CGI specific group, we deny it and improve security.

Some options, we might already implement:

error_reporting (1=on, 0=off; enable or disable displaying errors/warnings/notices)
include_path (additional include path to install in engine)
recursion_depth (set a recursion limit)
shell_exec (1=on, 0=off; enable or disable ability to use exec() alike builtin functions)

Other ideas are also welcome.

I think, this is a good idea, to save Interpreter configuration in INI file, like it is done in PHP, thus giving end user more control over it. However, I was thinking about doing it in a bit another way. [general] some_option=1 another option=1 [sapi:cli] some_option=0 [sapi:cgi] [module:dummy] dummy_specific=1 General idea, is to have single INI file for storing configuration. The __general__ section would store all interpreter's configuration, however any of them could be overwritten by SAPI-specific option. Thanks to that, end user could quickly and easily configure it, and still have some flexibility. Real life example: in general section we allow to use exec-alike functions, but in __CGI specific group__, we deny it and improve security. Some options, we might already implement: * error_reporting (1=on, 0=off; enable or disable displaying errors/warnings/notices) * include_path (additional include path to install in engine) * recursion_depth (set a recursion limit) * shell_exec (1=on, 0=off; enable or disable ability to use exec() alike builtin functions) Other ideas are also welcome.

belliash added the

enhancement

label 2018-07-31 13:50:51 +02:00

devnexen commented

2018-07-31 17:43:13 +02:00

Member

Does it have to be relatively similar to php's ? (for sort of quick migration purpose or any convenience)

belliash commented

2018-07-31 18:38:31 +02:00

Author

Owner

I would say it doesn't have to as php.ini is rather huge file containing a lot of options. Too much of them leads to inconsistency and be a cause of non-working scripts. There are already a lot of checks done by software written in PHP and a lot of errors due to some limits, encoding, etc. I was rather thinking about some basic options. I see some reason for already mentioned parameters:

error_reporting - when writing code, it is nice to have errors on output, especially when working with web sites, but not on production
include_path allows to include files from outside of webroot
recursion_depth will break script execution when function will call itself too much times
memory_limit will break script execution if interpreter tries to allocate more memory than allowed
shell_exec will allow or disallow of executing shell commands. Here I imagine, that exec() can simply return -1 and/or some warning/notice might be thrown.

I would say it doesn't have to as php.ini is rather huge file containing a lot of options. Too much of them leads to inconsistency and be a cause of non-working scripts. There are already a lot of checks done by software written in PHP and a lot of errors due to some limits, encoding, etc. I was rather thinking about some basic options. I see some reason for already mentioned parameters: * error_reporting - when writing code, it is nice to have errors on output, especially when working with web sites, but not on production * include_path allows to include files from outside of webroot * recursion_depth will break script execution when function will call itself too much times * memory_limit will break script execution if interpreter tries to allocate more memory than allowed * shell_exec will allow or disallow of executing shell commands. Here I imagine, that exec() can simply return -1 and/or some warning/notice might be thrown.

aaronduino commented

2018-07-31 19:58:12 +02:00

Although it may complicate things, maybe toml could be considered? It is similar to ini but feels a little less "janky" when it comes to complex configs.

I guess it depends on how complex the configs will get. If the plan is to keep them simple (simple is a good thing), then I agree that you can't go wrong with ini.

(Just providing ideas; not suggesting that something is wrong with the current plan)

Although it may complicate things, maybe [toml](https://github.com/toml-lang/toml) could be considered? It is similar to ini but feels a little less "janky" when it comes to complex configs. I guess it depends on how complex the configs will get. If the plan is to keep them simple (simple is a good thing), then I agree that you can't go wrong with ini. (Just providing ideas; not suggesting that something is wrong with the current plan)

belliash commented

2018-07-31 20:09:36 +02:00

Author

Owner

I don't say no. It looks very similar to old INI. What are the advantages of using TOML, except it has data types? I suppose the implementation will be more complex than simple INI...

devnexen commented

2018-07-31 20:09:52 +02:00

Member

Makes me think ... how external dependencies should be handled ? Checking at compile time or having the dependencies codebase somewhere (as php does sometimes but not ideal...), git reference ?. Other suggestions ?

aaronduino commented

2018-08-01 00:10:22 +02:00

@belliash for the most part, toml is just ini but with data types and support for more complex data structures (easier to do tables, lists, etc).

For the uses described above, it sounds like toml could be overkill, but maybe it could be used if future config files start getting to complex for clean-looking ini.

@belliash for the most part, toml is just ini but with data types and support for more complex data structures (easier to do tables, lists, etc). For the uses described above, it sounds like toml could be overkill, but maybe it could be used if future config files start getting to complex for clean-looking ini.

belliash commented

2018-08-01 06:36:45 +02:00

Author

Owner

I think INI is much easier to implement and it should be enough for current setup. However, if configuration file will grow, we can switch to TOML. It should give us backward compatibility and change should be transparent to end users.

belliash self-assigned this 2019-07-10 12:57:41 +02:00

belliash commented

2019-07-10 13:02:52 +02:00

Author

Owner

Interpreter itself should behave the exact way independent on its setting. If some restrictions are necessary for web specific scenario, they should be set by CGI/FCGI SAPI. Invalid for the moment.

belliash closed this issue

2019-07-10 13:02:52 +02:00

Interpreter configuration stored in INI file #32