You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For INI modules, the init method takes a parameter, which is used to retrieve module specific settings. The console module has no corresponding parameter. Perhaps we can generalize the INI approach to allow both types of modules to receive module specific settings.
In particular, there is nothing overly special about an INI section name. It is essentially just a handle that can be used to retrieve settings. The settings happen to use key/value lookups with strings. There are however some specifics that tie things to INI file access code. To abstract away the details, the modules can instead be passed an opaque pointer or handle which could later be used to retrieve module specific settings. With a handle the module doesn't need to know or care if the settings come from an INI file, command line options, or some other source. By making it opaque, the modules would not be dependent on the internal structure of the handle or what it points to.
From the module writer's perspective, the module might export something conceptually like:
Export voidInit(SettingsHandle settingsHandle);
The actual setting could be accessed through a new public interface method, which abstracts away the details of where the settings are read from:
auto length = GetSetting(settingsHandle, "IPAddress", ipAddrString.data(), ipAddrString.size());
The exported method should stick to a strict C interface, though would be easy enough to wrap and return a std::string.
The above interface would allow for abstracted key/value string lookups, associated with each module. None of it would rely directly on INI file related code.
If we wanted to extend it a bit further, and cover more of what INI files are capable of, we could also add other methods to retrieve a list of available keys. That may be out of scope though, as no modules currently make use of such a feature.
The details of how console modules would set and pass module specific settings is out of scope here, and will be the topic of a separate issue.
The text was updated successfully, but these errors were encountered:
For INI modules, the init method takes a parameter, which is used to retrieve module specific settings. The console module has no corresponding parameter. Perhaps we can generalize the INI approach to allow both types of modules to receive module specific settings.
In particular, there is nothing overly special about an INI section name. It is essentially just a handle that can be used to retrieve settings. The settings happen to use key/value lookups with strings. There are however some specifics that tie things to INI file access code. To abstract away the details, the modules can instead be passed an opaque pointer or handle which could later be used to retrieve module specific settings. With a handle the module doesn't need to know or care if the settings come from an INI file, command line options, or some other source. By making it opaque, the modules would not be dependent on the internal structure of the handle or what it points to.
From the module writer's perspective, the module might export something conceptually like:
The actual setting could be accessed through a new public interface method, which abstracts away the details of where the settings are read from:
The exported method should stick to a strict C interface, though would be easy enough to wrap and return a
std::string
.The above interface would allow for abstracted key/value string lookups, associated with each module. None of it would rely directly on INI file related code.
If we wanted to extend it a bit further, and cover more of what INI files are capable of, we could also add other methods to retrieve a list of available keys. That may be out of scope though, as no modules currently make use of such a feature.
The details of how console modules would set and pass module specific settings is out of scope here, and will be the topic of a separate issue.
The text was updated successfully, but these errors were encountered: