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

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

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

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

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

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

В конечном счете, "язык" является мягкой абстракцией, но да, края неоднозначны.

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

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

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

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

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

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

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

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

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

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

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

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

num_threads = 13
hostname = 'myhost'

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

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

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

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

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

Вы могли обратиться к теории вычисления для определения что количества как язык программирования. Если Ваш формат файла настройки полон по Тьюрингу тогда, он обоснованно рассчитывает как язык программирования. По этому определению, формат файла для описания уровней количества Sokoban как язык программирования (см. здесь ). Существуют другие уровни сложности ниже полного по Тьюрингу, который может также рассчитать, такой как Регулярные грамматики и Автоматы с магазинной памятью .

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

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

А хороший подход должен использовать приятно разработанный язык, сказать Python или рубин, и использовать его для создания DSL для конфигурации. Тем путем Ваш язык конфигурации может остаться простым на поверхности, но в на самом деле быть абсолютным языком программирования.

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

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

key = val
key2 = val
name = `hostname`

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

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

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

2. Иначе я считал его как есть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• они должны быть источником, которым управляют (см. вопрос 3)?

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

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

я только использую файлы конфигурации для указания на хранилища данных.