Parsing ini files

Typical section of an MS .ini file
Typical section of an MS .ini file

Following on from the v1.2 release, which addressed some of the data storage architecture in the app, I’ve been taking some time to review other aspects of the app.

The storage architecture is working really well, giving much improved performance as well as giving some enhanced ways of using and displaying the data within the app in the future.

Where the app is still struggling is when it comes to addressing the many and varied firmware and hardware versions. The original app was first written at a time when MS2 was cutting edge and MS2-extra was still in beta. As a result it seemed pretty straight forward to do away with the need for the app to ask the user which firmware was being used, possibly supplying a .ini file to use.

These days, however, the number of firmware and hardware versions is staggering and it seems that it is increasingly difficult to reliably decode the data from the different revisions even within the same firmware version.

So, my current focus is on producing a “universal” parsing engine within the app. Where currently the app has a number of hard coded parsers, one for each firmware version, this new one will effectively use the .ini file for it’s decisions allowing new firmware versions and revisions to more easily be supported. To avoid having the app processing the .ini file itself these will be pre-processed and the relevant data shipped with the app although these pre-processed files will also be updated from a web service, allowing new firmware versions to be supported without an app update.

The effect on performance in the app is yet to be gauged but should performance be reduced due to the “universal” parser I may end up retaining the hard coded parsers and only using the universal one for firmwares not supported in hard coding.