Я заметил, что тонны программ хранят информацию о конфигурации в различных иерархических ключах. Например, в Firefox about:config есть ключи, такие как network.http.pipelining и network.http.pipelining.ssl и network.http.use-cache . Я заметил этот стиль конфигурации в Firefox, в OS X (Library/Preferences), в sysctl , среди других. Почему это так часто? Была ли какая-то ранняя программа, которая использовала это, так что другие копировали это?
3
2 ответа
5
Это иерархическое соглашение призвано обеспечить ясность, помогая нам узнать сферу влияния каждого параметра и различить несколько параметров с одинаковым или неоднозначным именем среди различных модулей.
Это полезно в приложениях со слишком большим количеством возможных настроек, чтобы включить их в основные страницы параметров пользователя (где иерархия показана вкладками или страницами), и является хорошей альтернативой обычным файлам INI (с разделителями разделов [title] ), которые более склонны к ошибке пользователя и обычно требуют перезапуска приложения для вступления в силу.
Параметры иерархии также могут в определенной степени отражать внутреннюю нисходящую объектно-ориентированную модель, используемую разработчиками:
В этой примерной модели мы могли бы очень хорошо представить, что там установлено значение person.profestival.disallow_strikes = true, в то время как student.disallow_strikes может оставаться равным false или вообще не быть доступным. Эта компартментализация также является основой для пространств имен в языках программирования (и популярная платформа .NET придерживается того же соглашения об именах: using System.Threading.Tasks).
Итак, теперь мы можем предположить, что параметр network.http.xxx не должен влиять на network.ftp или другие сетевые подмодули, в то время как параметр network.xxx , вероятно, будет влиять на все из них.
Дополнительная информация полезна ...
для пользователя: у нас есть лучшее представление о том, на какую часть приложения будет влиять данный параметр, что облегчает устранение проблем (и позволяет избежать!)
и для разработчиков: человек, работающий над конкретным модулем или устраняющий его неполадки, может легко знать, какие изменяемые пользователем настройки могут повлиять на его / ее текущую работу, и сосредоточиться на этом.
4
Вы упомянули одну из основных причин в своем первом предложении: иерархические ключи.
Каждая группа ключей сгруппирована. Все связанные с сетью ключи являются сетевыми. Все связанные с http ключи - network.http.something и так далее. Это делает сам ключ несколько самодокументирующим, к чему относится значение. Если использовать стиль файла INI (который, как понятно, ничто не помешает вам использовать эти виды ключей, если вы хотите) с парами [section] и ключ = значение, данный ключ может быть неоднозначным, пока раздел не будет известен. Более того, размещение ключей в файле важно. Ввод ключа ssl в раздел [GUI], вероятно, является ошибкой и может привести к игнорированию ключа. Стиль abc должен означать, что порядок ключей в файле не имеет значения. Если вы читаете network.http.ssl.key =, не имеет значения, была ли предыдущая строка gui.background.color = или что-то еще. Полный ключ называется.
Почему это так часто? Это чертовски полезно, вот почему. Людям также легко читать и понимать (от ключа к ключу) и редактировать.
Откуда это? Я бы сказал, что структуры в стиле C, которые, вероятно, имеют происхождение, о котором я не знаю, и которые также проникли во многие другие языки программирования. Установка значения в структуре C будет иметь значение struct.property = value, а для вложенных структур struct.substructure.property = value и т.д. (Хотя в реальной жизни указатели вместо этого переводят многие из этих точек в ->, но это мелкая мелочь).