I am quite sure that this was discussed at the edge of another thread, but I didn't find it again... But it seems to gain some importance.
I came to this with the extensions I coded for ToggeleIcons and vSwitches. Both add new functionalities to the firmware and are related to the model config. So they should be written in the modelXX.ini.
But if done so, other versions of deViation might be confused about that. So from my point of view there should be a guideline how to deal with additions.
There are many ways to handle this. Just two:
- Indroduce version numbers to the model files and a user controlled method of converting them to each other version (as far as useful), either in the tx or on PC.
- Every addition defines its own section/subsection and attribute names which are unique. These should be ignored by versions of deViation which do not make use of them. This sould make sure, that a model file is interpreted correctly in every version while the additions can be used. One problem might be that the old values are not configured when the new are so using a newer model file with an older version leaves some aspects uninitialized. Another problem is that only known values are stored in the model object and so they are not written back to the file when saving.
There are also a few possibilities how/when to convert model files (I have to say I am no friend on invisible conversion in the background without user's control)(and tx-based conversion will eat up RAM/ROM on smaller devices):
- When a model-file was recognized as from the old firmware, don't offer the new possibilities
- When a model-file was recognized as from the old firmware, don't save the new assignments when the file is written (just the rest of the config and the old values)
- When a model-file was recognized as from the old firmware, convert it either automatically or after user's confirmation
- When the tx is booted, check all model files for older versions and convert them, either automatically or after user's confirmation
- Take some PC based tool to convert between the different version
Maybe this will happen in the future at some points where functionality needs new model configuration parameters or maybe an new interpretation of existing parameters. So I think a comprehensive solution or guideline would be necessary.
