Currently apptools.preferences uses .ini files mediated by ConfigObj. This was a reasonable choice in 2008, but now there are other possible configuration file formats that might be reasonably used. Candidates include:
Different applications may want to used different formats because they are easier to manually write, or because they need to be interpreted by other systems where .ini format does not have an easily available reader; or integrate with existing systems which have made different choices. Also the long-term future of ConfigObj is unclear - it works, but is also not being updated frequently.
Fortunately the actual file-handling code in the main Preferences is wholly contained within the save and load functions. It would be straightforward to add hooks to read from different formats based on file extensions; and to write to a particular format based on configuration of the preferences system.
One consideration is that the current system assumes that all data is text, while other systems permit additional data types for things like numbers, lists and mappings. This is primarily an issue for reading of files, particularly if they have been manually edited; other value types may need to be explicitly cast to strings.
Similarly, other formats have notions of hierarchical structure which have been imposed on the .ini format manually (by .-separated section names). Some thought may need to be put into how we want to handle this: do we want a flat structure with .-separated sections, or a nested structure using the components.
Currently
apptools.preferencesuses .ini files mediated byConfigObj. This was a reasonable choice in 2008, but now there are other possible configuration file formats that might be reasonably used. Candidates include:Different applications may want to used different formats because they are easier to manually write, or because they need to be interpreted by other systems where .ini format does not have an easily available reader; or integrate with existing systems which have made different choices. Also the long-term future of
ConfigObjis unclear - it works, but is also not being updated frequently.Fortunately the actual file-handling code in the main
Preferencesis wholly contained within thesaveandloadfunctions. It would be straightforward to add hooks to read from different formats based on file extensions; and to write to a particular format based on configuration of the preferences system.One consideration is that the current system assumes that all data is text, while other systems permit additional data types for things like numbers, lists and mappings. This is primarily an issue for reading of files, particularly if they have been manually edited; other value types may need to be explicitly cast to strings.
Similarly, other formats have notions of hierarchical structure which have been imposed on the .ini format manually (by
.-separated section names). Some thought may need to be put into how we want to handle this: do we want a flat structure with.-separated sections, or a nested structure using the components.