Здравствуйте, Sinclair, Вы писали:

S>Когда мы это размажем по иерархии веб-конфигов, всё станет ещё веселее.

В итоге этого можно относительно избежать, если конфиг делать в виде библиотеки, чтобы пользователь открывал IDE Собирал проект с зависимостями от неких публичных API приложения и тогда у него будет всё относительно доступно. Только конфиги почему-то обычно в блокнотике правят совсем не программисты.

K>>Что лучше бы программисты десяток типовых сборок сделало или реализовать удобный инструмент для настройки ПО, чем заставлять людей месяцами ковыряться в километровых конфигах неизвестно на каком языке.
S>У нас с вами разные понятия об удобстве инструментов для настройки ПО. Вот в примере выше в качестве языка управления конфигурацией мы породили некоторый DSL, для которого нет инструментов ни автодополнения, ни рефакторинга. Это нам ещё повезло — язык остался текстовым (а не представлен, скажем, в виде каких-то данных в РСУБД), поэтому мы хотя бы можем делать diff и blame.

xml, json, ini — большинству айтишников знакомы и понятны. Добавить раздел в xml или json сможет любой в блокнотике.
Чем ему поможет, если конфиг будет в виде какого-нибудь cs-файла с кодом на шарпе?

S>Даже в таком простом примере видно, что "простые значения" в конфиге должны быть согласованы между собой; но никаких средств проверки этого (кроме запуска приложения и тестирования сценариев) у нас нет.

Их не будет в любом случае

K>>Этот код выполнится в том же процессе и в том же домене. Запустил человек доверенную программу под админом, а там какой-то левый код побежал по файлам шуршать.
S>Ещё проще — человек запустил доверенное приложение под админом, а в нём — левый код.

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

S>Вы хотите избежать ситуации, когда админом запускается код, принесённый не-админом? Этот аспект отличается для серверных и настольных приложений.

Я хочу избежать ситуации, когда админ вынужден давать лишние права "не админам".

S>Но я всё ещё считаю, что это должен быть код на каком-то языке с нормальным тулчейном, а не просто плоский ini, или простынки json/XML.

Так я и говорю, что либо простой плоский ini/xml/json, либо отдельный человеческий инструмент, который даст пользователям нормально настроить программу

K>>Ну, конечно дома или в фирме на 30 сотрудников, есть админ, который ещё и осилит права правильно раздать.
S>Ещё раз: в такой фирме или дома, компьютер уже представляет из себя большую дыру. Люди гоняют скачанные из интернета екзешники под локальным админом и в ус не дуют.

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

K>>Только вот настраивается 1С Предприятие автоматически, а минимальные настройки для ключей и т.п. — обычные ini-файлы из десятка строк, где что-то сломать проблематично.
K>>А если конфигурацию из 1С считать конфигом, то в принципе любую программу можно считать им, особенно если там интерпретатор, а не компилятор.
S>Да, я предлагаю конфигурацию 1С считать конфигурацией. Ну, потому что это конфигурация.

Ну, значит программа на шарпе с использованием WPF и Entity Framework — это тоже некий конфиг
Конфигурация 1С — это не просто описание подключения неких модулей, а вполне себе и описание схемы БД и код всех методов.

S>А почему не хранить сам этот DTO в формате object initializer?
S>В отличие от json, этот код можно рефакторить, а написание оборудовано автодополнением.

Что-то там дописывать будут только разработчики, а пользователи и админы всякие туда залезают обычно — поменять пути к файлам, изменить какие-то константы, добавить пару строчек копипастой из документации от разработчиков.
Если уж конфиг нужно часто менять и сильно дописывать, то никто разработчикам не мешает сделать GUI-тулзу для заполнения этого json c валидацией.