#32 Interpreter configuration stored in INI file

Closed
opened 3 years ago by belliash · 8 comments
belliash commented 3 years ago
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 3 years ago
devnexen commented 3 years ago
Collaborator

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

Does it have to be relatively similar to php's ? (for sort of quick migration purpose or any convenience)
belliash commented 3 years ago
Poster
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.

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 3 years ago
Poster
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...

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 3 years ago
Collaborator

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 ?

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 ?

@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 3 years ago
Poster
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.

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 2 years ago
belliash commented 2 years ago
Poster
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.

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 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.