Конфигурация приложения: нужны ваши взгляды

Question

У нас есть приложение, написанное на c и некоторые новые модули в C++. Он работает на Linux. Приложение уже готово.

1. У нас нет общей конфигурации для приложения. Теперь мы планируем иметь конфигурацию для всего приложения. Итак, мы потратили некоторое время на это и разработали наши собственные (еще не реализованы).

2. Мы в основном думали о сохранении конфигурации в файле XML (app_config.xml) и определить политику для этого в другом файле XML (app_config_policy.xml)

3. Написать немногих API-интерфейсов (EX: write_Config, read_config, verify_config, notify_config и т. д.). Имена этих apis являются самоочевидными. При необходимости я могу предоставить дополнительную информацию.

4. Файл XML политика определяет ограничения конкретной конфигурации, длины, типов и т.д.

Теперь вопрос: Там может быть приложение, имеющее аналогичное требование. Я думал, прежде чем двигаться дальше с этим, возьмите некоторые экспертные материалы и приступите к их мнению.

1. Есть ли библиотека с открытым исходным кодом, которая делает это уже? Я узнал, что libconfig один, но он тяжелый и не потокобезопасный (сказал нам)?

2. Любые другие альтернативы (с открытым исходным кодом) вы все предлагаете для вышеуказанной общей проблемы?

3. Любые мысли или проектные мнения относительно того же самого?

Спасибо заранее! Santhosh

Answer 1

Вы должны использовать схему для проверки файла конфигурации xml.

Answer 2

В прошлом году я предложил щедрую информацию о языках конфигурации, отличных от XML, которые обеспечивают проверку схемы содержимого файла конфигурации. Было несколько разочаровывающих ответов, так как вы можете увидеть, следуете ли вы этому link.

Поэтому, если вы хотите проверить схему, я согласен с nfechner, что вы должны посмотреть на некоторые языки схемы для XML. Вы можете найти ссылки на некоторые из более известных в one или two статей в Википедии.

Если вы еще не готовы использовать XML, то вы можете зарегистрироваться Config4* (из которых я - сопровождающий). Я упоминаю об этом, потому что Config4 * предоставляет язык проверки схемы, который по меньшей мере на порядок проще в использовании, чем XML-схема. (The только другой язык конфигурации не-XML я обнаружил, что есть проверка схемы является YAML, но эта функциональность доступна только через Java или Ruby, API, что неудобно для/приложений C C++.)

Config4 * обеспечивает API C++, а не API C, но я подозреваю, что вам будет достаточно легко разместить обертку extern "C" вокруг полезного подмножества API.

Что касается безопасности резьбы ...Если ваши приложения будут читать файл конфигурации во время однопоточной инициализации и только после этого разрешить нескольким потокам запрашивать объект конфигурации, тогда я не думаю, что какая-либо синхронизация потребуется, так как несколько потоков будут вызывать операции только для чтения , Тем не менее, я подозреваю, что вы уже знаете это, и вы спрашиваете о безопасности потоков, потому что вы ожидаете, что некоторые потоки вызовут операции запроса в объекте конфигурации, в то время как другие потоки одновременно вызывают операции обновления на нем. Если бы вы могли привести примеры некоторых многопоточных вариантов использования, которые вы ожидаете иметь в своих приложениях, то это может помочь людям предложить советы, соответствующие вашим требованиям безопасности потоков. В качестве метода снижения производительности вы можете реализовать синхронизированную обертку делегирования вокруг API любой библиотеки конфигурации, которую вы используете. Например (псевдокод):

int config_lookup_int(const char * name) 
{ 
    int result; 

    get_mutex_lock(); 
    result = raw_api_lookup_int(name); 
    release_mutex_lock(); 
    return result; 
} 

Последнее сообщение. Пожалуйста, уточните функциональность notify_config, которую вы ищете.