Closed by commit ff610907

In T620#10727, @nrwahl2 wrote:

we will likely need some sort of internal API for these that the rest of the code must use to access options (rather than directly access them via getenv() etc.), so that we can guarantee we have one comprehensive list.

This is reasonable as a stylistic choice and as a reminder to update the meta-data when we add an option. However, it doesn't seem either necessary or sufficient in order to guarantee we have one comprehensive list.

In T620#10726, @nrwahl2 wrote:

I feel like internationalization might be easier if we store all the options (with their descriptions, etc.) in C files. Then we can generate XML on demand.

This may also reduce duplication: we can use bit flags for options that are applicable to more than one type of object. It looks like we could do this by referencing an XML entity. However, that strikes me as less intuitive, and it would make the XML files harder to parse. (Parsability by external tools seems like the main advantage of using a static XML file as the source of truth.)

Those are for T382

we will likely need some sort of internal API for these that the rest of the code must use to access options (rather than directly access them via getenv() etc.), so that we can guarantee we have one comprehensive list.

It might even be worthwhile to keep the OCF-like metadata in XML files to be used as the definitive list, with the sysconfig file, ReST files for the books, and C and Python data files created from it automatically via make targets. Alternatively, we could install the XML files, and C and Python APIs could parse them.

Also OCF_RESKEY_trace_dir, if we want to mention that one