В какой момент файл конфигурации становится языком программирования?

Ответ 1

Очень интересные вопросы!

Я имею тенденцию ограничивать мои файлы конфигурации очень простым "ключ = значение", потому что я полностью согласен с вами в том, что файлы конфигурации могут очень быстро стать полномасштабными программами. Например, любой, кто когда-либо пытался "настроить" OpenSER, знает, о чем вы говорите: это не конфигурация, это (болезненное) программирование.

Когда вам нужно, чтобы ваше приложение было очень "настраиваемым" способами, которые вы не можете себе представить сегодня, тогда вам действительно нужна система плагинов. Вам необходимо разработать приложение таким образом, чтобы кто-то еще мог закодировать новый плагин и подключить его к вашему приложению в будущем.

Итак, чтобы ответить на ваши вопросы:

• Какова истинная цель файла конфигурации?

  Я бы сказал, чтобы люди, которые установили ваше приложение, могли бы закрутить некоторые параметры, связанные с развертыванием, такие как имя хоста, количество потоков, имена необходимых вам плагинов и параметры развертывания для этих плагины (проверьте конфигурацию FreeRadius для примера этого принципа) и т.д. Определенно не место для выражения бизнес-логики.

• Должна ли быть сделана попытка сохранить конфигурационные файлы простыми?

  Конечно. Как вы сказали, "программирование" в файле конфигурации ужасно. Я считаю, что этого следует избегать.

• Кто должен нести ответственность за внесение изменений в них (разработчики, пользователи, администраторы и т.д.)?

  В общем, я бы сказал, администраторы, которые развертывают приложение.

• Должны ли они контролироваться источником (см. вопрос 3)?

  Я обычно не управляю исходными файлами самих конфигурационных файлов, но я управляю исходным кодом файла конфигурации шаблона со всеми параметрами и их значениями по умолчанию и комментариями, описывающими, что они делают. Например, если файл конфигурации имеет имя database.conf, я обычно контролирую исходный файл с именем database.conf.template. Теперь, конечно, я говорю о том, что я делаю как разработчик. Как администратор, я могу захотеть установить исходные параметры, которые я выбрал для каждой установки. Например, мы удаляем несколько сотен серверов удаленно, и нам нужно отслеживать их конфигурации: мы решили сделать это с помощью источника-контроля.

Изменить: Хотя я считаю, что вышеприведенное значение относится к большинству приложений, всегда есть исключения, конечно. Например, ваше приложение может позволить своим пользователям динамически настраивать сложные правила. Большинство почтовых клиентов позволяют пользователям определять правила управления своими электронными письмами (например, "все письма, поступающие с" john doe "и не имеющие меня в поле To: должны быть отброшены" ). Другим примером является приложение, которое позволяет пользователю определить новое комплексное коммерческое предложение. Вы также можете подумать о таких приложениях, как Cognos, которые позволяют своим пользователям создавать сложные отчеты по базам данных. Клиент электронной почты, вероятно, предложит пользователю простой интерфейс для определения правил, и это создаст сложный файл конфигурации (или даже, возможно, немного кода). С другой стороны, пользовательская конфигурация для коммерческих предложений может быть сохранена в базе данных структурированным способом (ни простая структура ключа = значение, ни часть кода). И некоторые другие приложения могут даже разрешить пользователю кодировать в python или VB, или какой-либо другой язык, поддерживающий автоматизацию. Другими словами... ваш пробег может отличаться.

Ответ 2

Ok. У вас будут некоторые пользователи, которым нужна действительно простая конфигурация, вы должны отдать их им. В то же время у вас будут постоянные запросы "Можете ли вы добавить это? Как это сделать в файле конфигурации?", Я не понимаю, почему вы не можете поддерживать обе группы.

Проект, над которым я сейчас работаю, использует Lua для своего файла конфигурации. Lua - это язык сценариев, и он хорошо работает в этом сценарии. Существует пример нашей конфигурации по умолчанию.

Вы заметите, что это в основном ключевые слова = значения, где значение может быть любым из встроенных типов Lua. Самое сложное, что есть списки, и они не очень сложны (это просто вопрос синтаксиса).

Теперь я просто жду, когда кто-нибудь спросит, как устанавливать свой порт сервера на случайное значение каждый раз, когда они запускают его...

Ответ 3

Недавно я работал над проектом, и я понял, что хочу иметь условные обозначения внутри своего конфигурационного файла, который ранее был довольно простым в форме:

key = val
key2 = val
name = `hostname`

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

Вместо этого я решил, что у меня будет две формы:

• Если файл начинался с "#!" и был исполняемым, я проанализировал результат его запуска.

• В противном случае я бы прочитал его как-есть

Это означает, что теперь я могу позволить людям писать "файлы конфигурации", которые выглядят следующим образом:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

Таким образом, я получаю мощь динамического файла конфигурации, если пользователь хочет его использовать, и простота в том, чтобы не писать собственный мини-язык.

Ответ 4

Каждая (достаточно долговечная) конфигурация файла конфигурации в конечном итоге становится языком программирования. Из-за всех последствий, которые вы описываете, для дизайнера конфигурационных файлов разумно понять, что она является автором языка программирования и соответствующим образом спланирована, чтобы она не подвергла будущих пользователей плохому наследию.

Ответ 5

У меня есть другая философия о файлах конфигурации. Данные о том, как приложение должно выполняться , по-прежнему являются данными и поэтому принадлежат в хранилище данных, а не в коде (файл конфигурации IMO - это код). Если конечные пользователи должны иметь возможность изменять данные, приложение должно предоставить интерфейс для этого.

Я использую только файлы конфигурации, чтобы указывать на хранилища данных.

Ответ 6

Вы можете обратиться к теории вычислений, чтобы определить, что считается языком программирования. Если ваш формат файла конфигурации Turing Complete, то он разумно считается языком программирования. По этому определению формат файла для описания уровней Sokoban считается языком программирования (см. здесь). Существуют другие уровни сложности ниже Turing Complete, которые могут также учитываться, например Regular Grammars и Pushdown Automata.

Другой способ взглянуть на это состоит в том, что многие файлы конфигурации способны только разметки данных, тогда как правильный язык программирования должен иметь возможность реализовывать алгоритмы . Например, JSON - это формат файла конфигурации, тогда как ECMA Script - это язык программирования.

Ответ 7

Вот мои мысли:

• Чтобы легко изменять поведение приложения в режиме исполнения. Это могут быть программисты или не программисты, в зависимости от потребностей. Это может быть во время разработки, но я часто рассматриваю файлы конфигурации как способ сделать программу более гибкой в ​​любой момент.

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

• Зависит от того, что и почему происходит изменение. Если пользователи будут его менять, необходимо закрыть переднюю панель, чтобы скрыть их от деталей. То же самое часто относится к не-разработчикам в целом.

• Я часто контролирую конфигурацию по умолчанию, но имею возможность переопределить это для каждой системы для фактического времени выполнения.

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

Ответ 8

Это зависит от того, что вы согласны с другими разработчиками в команде. Вы используете файлы конфигурации так же, как файлы конфигурации, или создаете приложение Model Driven.

Симптомы конфигурационного файла, которые становятся языком программирования:

• имя = пары значений начинают зависеть друг от друга
• вы чувствуете потребность в управлении потоком (например, если (это), чем это)
• документация для файла конфигурации становится необходимой для дальнейшей разработки (вместо использования приложения)
• до считывания значения из config требуется, чтобы он имел некоторый контекст (то есть значения зависели от чего-то внешнего файла конфигурации)

Ответ 9

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

Хороший подход - использовать хорошо разработанный язык, например python или ruby, и использовать его для создания

Ответ 10

Я считаю, что ваш вопрос очень важен, учитывая переход на "свободные интерфейсы". Многие разработчики "видели свет" в отношении настроенных XML-приложений. Использование XML может быть очень многословным и трудным для правильного редактирования (особенно если схема не предусмотрена). Наличие свободного интерфейса позволяет разработчику настраивать приложение на языке, специфичном для домена, с помощью некоторых пар ключ-значение из файла конфигурации обычного текста (или, возможно, параметров командной строки). Это также упрощает настройку и настройку новых экземпляров приложения для тестирования или что-то еще.

Вот мои ответы на ваш вопрос:

• Какова истинная цель конфигурации файл?

Файл конфигурации - это способ, позволяющий пользователю настраивать поведение своей программы во время выполнения.

• Следует попытаться сохранить Конфигурационные файлы просты?

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

• Кто должен нести ответственность за изменения в них (разработчики, пользователи, администраторы и т.д.)?

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

• Если они находятся под контролем источника (см. вопрос 3)?

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

Ответ 11

Я склонен согласиться с предпосылкой этого вопроса. Я избегаю попадания в неприятности, заранее предсказывая, что это произойдет, и поэтому никогда не переверните мою собственную конфигурационную систему.

• Либо я использую конфигурацию конфигурации операционной системы (например, plist, или gconf или что-то подходящее),
• Или простой плоский файл, который может обрабатываться чем-то вроде анализатора INI на полке.
• Укусить пулю и подключить легкий синтаксический анализатор языка, обычно lua, иногда tcl в приложение,
• Или хранить данные в SQLite или подобной реляционной базе данных.

И смирись с тем, чтобы жить с любым решением, которое я принял, или, если я не могу, рефакторинг использовать один из вышеперечисленных вариантов, который лучше подходит для приложения.

Точка, на самом деле нет причин использовать домашнее конфигурационное решение. Во-первых, для ваших пользователей сложнее изучить новый конфигурационный формат приложения. Для других вы получаете выгоду от всех исправлений ошибок и обновлений, которые предоставляются бесплатно при использовании готового решения. Наконец, функция creep ставится на отдых, потому что, на самом деле, вы фактически не можете просто добавить еще одну функцию, не выполняя капитальный ремонт, потому что система конфигурации на самом деле не в ваших руках.

Ответ 12

Да, файлы конфигурации должны быть простыми. Они не должны содержать никакой "логики" - считайте их как список выражений в операторах if, а не условных операторах в целом.

Они там, чтобы позволить пользователю решить, какой из вариантов, закодированных в приложении, должен использоваться, поэтому не пытайтесь усложнить их, это в конечном итоге саморазрушится - вы можете написать простые файлы конфигурации для управления тем, как исходный конфигурационный файл должен быть настроен в противном случае!

Ответ 13

Одной из целей работы "Осло" в Microsoft является разрешение (хотя и не требующее) разрешения этой проблемы.

• Приложение будет поставляться с моделями любых новых компонентов, которые он включает. Он также будет использовать существующие модели. Например, он может включать веб-службу, поэтому он может повторно использовать системную модель веб-службы.
• Модели будут включать в себя метаданные, описывающие их, включая достаточную информацию для инструментов для их доступа, текстовую или графическую.
• Части моделей будут соответствовать "конфигурации"

Это означает, что эквивалент сегодняшних файлов конфигурации может быть достаточно богат, чтобы поддерживать текстовое и графическое редактирование их конфигурации. Графический инструмент будет снабжен "Осло" (кодовое имя "Квадрант" ).

Ответ 14

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

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

В конечном счете, "язык" - это squishy абстракция, но да, края неоднозначны.

Ответ 15

Код наших приложений становится менее важным... Существует сценарий, есть все виды атрибутов, которые определяют поведение классов, методов, аргументов и свойств метода. Пользователи могут определять триггеры базы данных и ограничения базы данных. Могут быть очень сложные файлы конфигурации. Иногда пользователь может определять стили XSLT для управления вводами и выводами, потому что наши системы должны быть открыты (SOA). И есть такие вещи, как BizzTalk, который тоже нуждается в сложной конфигурации. Пользователи могут определять сложные рабочие процессы.

Нам нужно написать лучший код для работы с этой сложной средой, поэтому код наших приложений становится более важным...

Ответ 16

Я видел программы python, где файл конфигурации - это код. Если вам не нужно ничего делать (условные и т.д.), Он не сильно отличается от других конфигурационных стилей. например Я мог бы создать файл config.py с такими вещами, как:

num_threads = 13
hostname = 'myhost'

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

Ответ 17

Я большой поклонник использования программ python в качестве файлов конфигурации, особенно для демонов. Мне нравится придерживаться того, чтобы сделать демон совершенно пустым от конфигурации, кроме "порта конфигурации". Затем программа python соединяется с демоном и продолжает создавать объекты в демоне и соединяет их вместе для создания нужной конфигурации. После того, как все настроено, демона можно оставить для запуска на нем. Разумеется, преимущества в том, что вы получаете полноценный язык программирования для записи ваших файлов конфигурации, и поскольку у вас уже есть способ поговорить с демоном из другой программы, вы можете использовать его для отладки и получения статистики. Основной недостаток - иметь дело с сообщениями из другой программы, приходящей в любое время.