The JADE 2022 release meets tomorrow’s business demands.
Since jade v5 through to present there have been many INI keys and sections that have been added, deleted and changed but there has never been a safe and easy method to sanity check and verify correct syntax and values.
As INI updates are typically manual it is quite easy to make a mistake during updates.
INI's may also contain custom settings, named section settings and comments which an auditing tool would need to cater for.
Something as simple as highlighting sections that are not Jade specific or keys that are no longer in use would be helpful.
Guest
The JEDI Review decided that we wouldn't provide an "INI Cleaner", however we are undertaking a review of this part of the product, so I have moved this JEDI to Under Consideration so we can take your requirements into consideration in the review. Cheers John R.
Attachments Open full size
It *should* be possible for the product to know what's a valid setting, but it currently isn't. There is no central registry of settings. There is a central registry of *public* settings, and that's the documentation.
One of the reasons I suggest simply starting from a default ini file is that it's not only keys that become stale, it's values, too. One source of this is that old JADE used to write the literal values out to the keys, it was reasonably recently that the "<default>" value came into being. The biggest problem here is not stale keys- they do nothing except confuse developers. Stale values, on the other hand, genuinely affect the performance of the system.
If the function of a setting is not obvious, i.e. in the documentation, then it is Unpublished, and you should only be using it under the advice of JADE Support. If the effect of the setting is difficult to ascertain, then it is, by definition, non-critical.
Attachments Open full size
@Blake, It should be possible for the product to identify valid jade keys which will leave those that are not, and those must be either custom or jade ones that have been relinquished.
@Ty, That could become a very time consuming exercise as the function of a key may not be immediately obvious or could affect behavior that is difficult to ascertain.
Attachments Open full size
Why not just start with a fresh ini file, barring those keys you *know* you need?
Attachments Open full size
How would you determine keys that are not in use?
Attachments Open full size