XML vs рукописный формат для конфигов - Философия программирования

Здравствуйте, Павел Кузнецов, Вы писали:

>> Это уже ограничение

ПК>В XML, как и в любом другом формате, тоже есть свои ограничения.
Я имею ввиду сравнительные характеристики. Ты представил обычный ini файл, и противопоставил его xml.

>> Непонятно тогда, они как бы расширили семантику языка. А что будет если ctrl и shift я реверсну. То есть напишу наоборот: shift ctrl.

ПК>А что будет, если то же самое я сделаю в XML, приведенном выше Владом?
А я и не говорил что написанное Владом мне нравится. Первый вариант представленный eao197 мне больше нравится.

ПК>А в фрагменте соответствующего XML?
ПК>

ПК><Area Name="Application">
ПК>   <Shortcut Key"ContextMenu" Command="Show context menu" />
ПК></Area>
ПК>

ПК>?
Во первых, то что в xml находится ошибка.

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

<Area Name="Application">
     <ShortCuts>
        <Shortcut Key="ContextMenu" Command="Show context menu" />
     </ShortCuts>
</Area>

Теперь здесь уже понятно что только то что относится к ShortCuts

ПК>В т.ч. и "Key|ctrl|shift" vs. "Key|shift|ctrl"? Все равно, какая бы ни была схема, окончательной проверкой служит парсер, поставляемый в составе приложения, для которого этот конфиг написан.
По поводу формата уже ответил. Это связанно именно с данным фактом. Хотя эти значения можно типизировать через xsd, только когда проще, тогда лучше.

С уважением, Gleb.

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

E>>Как раз тащить для парсинга конфига XML-библитеку вроде Xerces или libxml2 -- это действительно круто

E>>Другое дело языки вроде Java/C# или даже скриптовые -- там поддержка XML уже чуть ли не встроенная.
E>>Только, имхо, забота там идет не о пользователе конфига, а о программисте, которому проще готовую структуру на XML замапить.
GZ>Я не очень представляю окружение в котором работают твои программы(за пределами DOS/Windows никогда не работал, в многоплатформенных приложениях я лох). Но поясни мне такую вещь. У тебя есть приложение на сервере. Поскольку приложение использует config файл, то функциональность xml уже на сервере присутсвует. Зачем перекатывать сново?

Как раз пока мне не очень требовался xml. Я все больше по двоичным GSM и SMPP протоколам специализируюсь. Там, к счастью, XML пока не пахнет

GZ>>> Можно конечно сделать xslt с вставками JavaScript, но зачем?
E>>Вот это, действительно, зачем?
GZ>А зачем Perl или Python?

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

{sysconf-script

    {load-dll    "so_sysconf.breakflag_handler"
        {alias    "so_sysconf_2::breakflag_handler"}
        {os-name-convert    "simple" }
    }
    {reg-coop    "so_sysconf_2::breakflag_handler::system_break_handler" }
    {reg-coop    "so_sysconf_2::breakflag_handler::user_break_handler" }

    {load-dll    "so_sysconf_log.sysconf"
        {alias    "so_sysconf_log_1::sysconf" }
        {os-name-convert    "simple" }
    }
    {reg-coop    "so_sysconf_log_1::sysconf::log" }

    {load-dll    "gemont.retranslator.sysconf"
        {os-name-convert    "simple"}
        {alias    "gemont_1::retranslator::sysconf"}
    }
    {reg-coop    "gemont_1::retranslator" }

    {load-dll    "mbapi.mbox.gemont.sysconf"
        {os-name-convert    "simple" }
        {alias    "mbapi_3_mbox::gemont"}
    }
    {reg-coop    "mbapi_3_mbox::gemont" }
    ...
}

Декларативное, в общем-то описание. Только по ходу эксплуатации выяснилось несколько подводных камней.
Например, на разных платформах имя DLL строится по разному. Например, под Win -- это mbapi.mbox.gemont.sysconf.dll. А в Unix-e -- libmbapi.mbox.gemont.sysconf.so. Для борьбы с этим явлением (для того, чтобы конфиг можно было просто копировать как на Win, так и на Unix) пришлось добавить специальный тег {os-name-convert} который указывает, каким образом нужно преобразовывать имя DLL (в перспективе он так же может содержать набор путей, в которых следует искать DLL).
Еще одна фича была бы полезной: выполнять блок инструкций только при выполнении некоторых условий. Например, есть какая-то DLL-ка присутствует. Или если работа идет на определенной платформе. Делать такую условную обработку на тегах, имхо не очень хорошо -- это повторное изобретение Curl-а или Lisp-а.

Было бы интересно для этих целей встраивать в приложение Ruby-интрепретатор и писать конфигурирование как-то так:

sysconf_script do |s|
    s.load_dll "so_sysconf.breakflag_handler", os_name_convert => [ :simple ] do |dll|
        dll.reg_coop "so_sysconf_2::breakflag_handler::system_break_handler"
        dll.reg_coop "so_sysconf_2::breakflag_handler::user_break_handler"
    end
    if s.platform != "SPARC Solaris"
        s.load_dll "gemont.retranslator.sysconf", os_name_convert => [ :simple ] do |dll|
            dll.reg_coop "gemont_1::retranslator"
        end
    end
    s.load_dll "mbapi.mbox.gemont.sysconf", os_name_convert => [ :simple ] do |dll|
        dll.reg_coop "mbapi_3_mbox::gemont"
    end
end

E>>А то, что многим админам приходится xml-ные конфиги править -- это еще не означает, что им нравится это делать

GZ>Многим нравится.

Я свидетель.

Видишь, у разных людей разный опыт

... << RSDN@Home 1.1.4 stable rev. 510>>

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

E>>Имхо, для многих админов тот же Perl или Python совсем не чужой язык.
GZ>Для меньшинства админов. И поскольку это не есть основной инструмент админа, то познания и навыки могут быть ниже среднего.

Не надо уж админов за дебилов держать. Хотя, конечно, я забыл. Вы ведь под Windows только работали. Там, может быть, от админов таких фундаментальных знаний и не требуют — главное уметь мышкой по табам кликать и xml в редакторе уметь писать.

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

E>Как раз пока мне не очень требовался xml. Я все больше по двоичным GSM и SMPP протоколам специализируюсь. Там, к счастью, XML пока не пахнет

Не зарекайся. Лет 5 назад я и не представлял что xml будут пихать во все места попавшиеся под руку.

GZ>>>> Можно конечно сделать xslt с вставками JavaScript, но зачем?
E>>>Вот это, действительно, зачем?
GZ>>А зачем Perl или Python?

E>На счет Perl-а не знаю, а вот Python или Ruby в качестве языка конфигурирования приложения я бы себе вполне мог представить.
Веришь, нет. Xslt для того и сделали, чтобы трансформировать xml в другой xml или html. Там возможно и выполнение JavaScript(и великий VBScript в Microsoft парсере ессно). Такая функциональность на нем возможна.

С уважением, Gleb.

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

Q>Не надо уж админов за дебилов держать.
Это твои слова. Я никогда такого не говорил и не скажу.
Q>Хотя, конечно, я забыл. Вы ведь под Windows только работали. Там, может быть, от админов таких фундаментальных знаний и не требуют — главное уметь мышкой по табам кликать и xml в редакторе уметь писать.
Уважаемый. Я не делаю приложения для обслуживания операционной системы. Я делаю коммерческие продукты для конечных пользователей. Позволю вам напомнить, что админы разные бывают. Есть админы операционных систем, баз данных. А есть админы крупных enterprize систем. И они вообще не обязаны знать какой-либо язык. Они должны быть проффесионалы в той предметной области, которую они администрят. И я, в 90 процентах случаев, я общаюсь именно с этими людьми. Это в большинстве случаев высокопроффесиональные специалисты. И вы предлагаете уволить и нанять вместо них программистов?

С уважением, Gleb.

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

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

E>>Как раз пока мне не очень требовался xml. Я все больше по двоичным GSM и SMPP протоколам специализируюсь. Там, к счастью, XML пока не пахнет

GZ>Не зарекайся. Лет 5 назад я и не представлял что xml будут пихать во все места попавшиеся под руку.

А чего зарекаться-то?

SMS Forum уже выпустила спецификацию MMAP -- SMS транспорт на основе SOAP.
Кроме того, я знаю, что есть операторы, которые обеспечивают интерфейс к своему SMS-центру на основе самописных XML-протоколов.
Маразм крепчал, короче.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>В любом случае, вопрос остается: зачем в данном случае вложенные теги, если описываемая информация не иерархична?

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

... << RSDN@Home 1.2.0 alpha rev. 611>>

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

Q>В обычном конфиге, можно подумать, ставит.

Интересно, что все разговоры о самопальных конфигах и применении разных Яков для их создания рано или поздно сваливаются в обсуждения XML vs. INI. А гед же Яки?

... << RSDN@Home 1.2.0 alpha rev. 611>>

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

E>Особенно классно это делать в текстовом режиме через ssh на медленном канале. И когда из-за какой-нибудь форс-мажорной ситуации тебя будят в три часа ночи, чтобы работоспособность системы восстановить.

Терминалка работает через диалап на ура. Не "Формула 1" конечно, но вполне приемлемо.

... << RSDN@Home 1.2.0 alpha rev. 611>>

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

E>Другое дело языки вроде Java/C# или даже скриптовые -- там поддержка XML уже чуть ли не встроенная.

Из твоих же примеров мы узнали, что в Руби с ХМЛ-ем тоже все в пордяке.

E>Только, имхо, забота там идет не о пользователе конфига, а о программисте, которому проще готовую структуру на XML замапить.

Невреная постановка вопроса. Речь идет об удобстве как программиста, так и пользователя. ХМЛ — это стандарт. А стандарты позвляют уменьшать необходимость тратить время на изучение нестандартных фичь и приспосабливание к ним.

E>Имхо, для многих админов тот же Perl или Python совсем не чужой язык.

Для некоторых. Про многих это ты загибашь. Но у этих языков тоже проблем с ХМЛ-ем нет. Да их ни у одного современного языка на сегодня нет по большому счету.

E>С++, к примеру, тоже можно вечно изучать. Да только многие не хотят этого делать, на более удобные, для себя, технологии переходят.

Это что. Некоторые переходят изучив. А некоторые боятся перейти.

E>А то, что многим админам приходится xml-ные конфиги править -- это еще не означает, что им нравится это делать

Дык ты спроси их что им проще править конфиги на Курле или на ХМЛ-е. А то им вообще работать может не нравится.

... << RSDN@Home 1.2.0 alpha rev. 611>>

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

Q>Не надо уж админов за дебилов держать. Хотя, конечно, я забыл. Вы ведь под Windows только работали. Там, может быть, от админов таких фундаментальных знаний и не требуют — главное уметь мышкой по табам кликать и xml в редакторе уметь писать.

Полностью согласен. Как в прочем и с тем, что на разных Нисанах нужно только уметь перевести машину с паркинга на ход вперед и жать на газ и тормаз. Вот только чувствую, что это, по-втоему, плохо, а стало быть плох и порочен сам Нисан. То ли дело раздолбанные Жигули. А что там Жигули? Запор горбатый... вот это романтика!!!

Чтобы завести нужно подтолкнуть или ручку подкрутить. По воскресеньям акумулятор перезарядить. Едишь... так вообще кайф. Все вокруг свистит уже на 60-ти, а на 80-ти скорость чувствуется как в гоночном болиде... машину кидает из стороны в сторону... мотор ревет как зверь... то и дело нужно жать сцепление и переключать скорости... в салоне жарко... В общем одни удоволствия. А эти ламеры на Нисанах, БэЭмВэхах и других Мерседесах — они же ламеры. Они же только и способны как по прямым дорогам ездить.

А как им приятно сказать "Вы ведь только на Нисанах и ездели...".

В общем, не нужно окружающих за дебилов считать. Хотя конечно я забыл. Если человек под Линукс посидел, то это становится в норме вещей.

... << RSDN@Home 1.2.0 alpha rev. 611>>

Здравствуйте, Павел Кузнецов, Вы писали:

>> ПК>Нет, она всегда UTF-8.

>> Это уже ограничение

ПК>В XML, как и в любом другом формате, тоже есть свои ограничения.

Хорошо так в воздух умную фразу бросил. Вот только в ХМЛ кодировка задается в начале файла. И она может быть хоть UTF-16, хоть 1251.

>> Непонятно тогда, они как бы расширили семантику языка. А что будет если ctrl и shift я реверсну. То есть напишу наоборот: shift ctrl.

ПК>А что будет, если то же самое я сделаю в XML, приведенном выше Владом?

Ничего не будет. Я не даром "|" за разделитель принял. Можешь хоть "Shift | Shift | Shift" написать. Будет их побитовое сложение. А на не поддерживаемый идентификатор ругань будет. Только это к ХМЛ отношения не имеет. Это уже внутренний парсинг силами дотнета.

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

ПК>А в фрагменте соответствующего XML?
ПК>

ПК><Area Name="Application">
ПК>   <Shortcut Key"ContextMenu" Command="Show context menu" />
ПК></Area>
ПК>

ПК>?

Даже это понять проще, а если еще специально не косячить...

... << RSDN@Home 1.2.0 alpha rev. 611>>

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

VD>В данном случае вложенность одиночная, а информации в тегах ровно столько чтобы было без дополнительных объяснений ясно о чем идет речь. А вот в более сложном случае (о чем я гворил в выделенном тексте) у инифайлов бвли бы серьезные проблемы. Пришлось бы впихивать невпихуемое.

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

XML:
<for from="0" to="10"> content </for>

C-like:
for(from=0 to=10) { content }

Причем, в подавляющем большинстве случаев, аттрибутов нет.

XML:
<for> content </for>

C-like:
for{ content }

А самое главное — комментарии. Ну дайте-дайте мне "//" в XML! Хотя бы только в начале строки.
XML — это форменное издевательство над мозгом. И придумал этот синтаксис какой-то пакостник.

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

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

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

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

MS> Что, XML-парсеры настолько тупые, что им надо по два раза все объяснять?

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

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

<Shortcut Key="Home" Action="..." />

Но когда внутри тега множество других, то человеку тяжело увидеть что за тег закрывается. Например, гипотетический ХМЛ в котором можно размещать вложенные теги так как это делается в Лиспе:

<Shortcuts
    <Shortcut Key="..." Action="..." />
    <Shortcut Key="..." Action="..." />
    <Shortcut Key="..." Action="..." />
    <Shortcut Key="..." Action="..." />
    <Shortcut Key="..." Action="..." />
    <Shortcut Key="..." Action="..." />
    <!-- и так пара экранов... />
    <Shortcut Key="..." Action="..." />
    <Shortcut Key="..." Action="..." />
    <Shortcut Key="..." Action="..." />
    ...
/>

Находясь на последнем экране уже не просто понять что за тег закрыт. Указание же имени тега при закрытии упрощает чтение.

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

... << RSDN@Home 1.2.0 alpha rev. 611>>

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

VD>Парсерам конечно пофигу. Они очень даже неплохо парсят даже такие на первый взгляд не читаемые кострукции как исходники на Лиспе. А вот человеку совсем не по фигу. Человек хочет иметь что-то за что можено зацепиться взглядом. Когда тег вмещается на одну строку, то возможно закрывающий тег и не обязателен.

Этот аргумент не выдерживает ни малейшей критики. Если у нас все написано в одну длинную строку, здесь нам никакие имена в закрывающих тагах не помогут — сплошной поток крокозябликов в любом случае. Чтобы человеку прочесть, надо этот поток прогнать через некий beautifier, который обозначит структуру методом форматирвания с отступами. Если отформатировать, но без отступов, то имена точно так же бесполезны, поскольку структуры не видно. Следовательно, визуальная структура первична! Именно за нее "зацепляется взгляд", а не за имена закрывающих тагов. Ну а для эстетов — пожалуйста, пишите закрывающие имена в комментариях.

А тут получается "пинками в рай". А я не люблю, когда меня пинкаим, пусть даже и "в рай". А XML — это очень даже не рай. И вообще, худшее наказание для C# программиста, которое только можно придумать — это переписать весь код на XML. Вручную!

public void foo(int a, double b)
{
   return System.Math.Sin(b) * a;
}

XML:
<method access="public" return="void" name="foo">
   <args>
      <arg type="int" name="a"/>
      <arg type="double" name="b"/>
   </args>
   <body>
      <!-- Все, больше не могу!!! -->
   </body>
</method>

Вот что получается, когда вопросы стандартизации доверяют людям от сохи (не обращайте внимания, это я очень зол на W3C за их ублюдочный SVG

)

VD>Между почим я не редко встречал очень похожую кострукцию в С++-ном коде. В нем, после закрывающей скобки ставится комментарий говорящий, что эта скобка закрывает. Мне так писать влом, да и часто забывал бы менять коментарии после изменения кода, но читать такой код очень даже удобно.

Во-во. А почему тебе влом это писать? Не задумывался?

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

VladD2,

> Как в прочем и с тем, что на разных Нисанах нужно только уметь перевести машину с паркинга на ход вперед и жать на газ и тормаз. <...> То ли дело раздолбанные Жигули. <...> то и дело нужно жать сцепление и переключать скорости...

У тебя неправильный Ниссан. В правильных тоже нужно жать сцепление и переключать скорости.

Posted via RSDN NNTP Server 2.0 beta

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

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

E>>Другое дело языки вроде Java/C# или даже скриптовые -- там поддержка XML уже чуть ли не встроенная.

VD>Из твоих же примеров мы узнали, что в Руби с ХМЛ-ем тоже все в пордяке.

Так я же и сказал (см.выделенное).

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

VD>Тут дело в том, что сколько людей столько и мнений. Но стандарт на то и стандарт чтобы быть единым. По этому нужно просто расслабиться и понять, что все в этой жизни по твоему быть просто не может и списать это дело на угоду чужим вкусам ради стандартизации.

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

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

grep --recursive --extended-regexp "((([[[:digit:]]{1,3}\.){3}[[[:digit:]]{1,3}|[[[:xdigit:]]{8})){0,1}:[[[:digit:]]+" .

давайте записывать:

grep <params><recursive/><extended-regexp/>((([[[:digit:]]{1,3}\.){3}[[[:digit:]]{1,3}|[[[:xdigit:]]{8})){0,1}:[[[:digit:]]+<path>.</path></params>

А чего? В приложении, как правило и так есть работа с XML, так зачем нам еще какую-то библиотеку парсинга аргументов командной строки брать. Ты, кстати, Влад, никогда не парсил аргументов с помощью Getopt разбирать (чтобы аргументы в GNU-соглашениях были)?

Во-вторых, стандарты, это очень относительная штука. Был такой стандарт объектных баз данных ODMG. И хоть мне он казался не жизнеспособным, когда я пытался делать свою объектную БД, мне часто говорили: "мол, стандарт-то ты не поддерживаешь, а стандарт -- он для того и стандарт". В результате ODMG благополучно забыт. На C++ так же есть стандарт, что не мешает разным крупным производителям компиляторов добавлять в C++ разные несовместимые расширения (тот же Borland, например). Еще есть POSIX, на который Microsoft-у чихать с большой колокольни. Так что стандарт имеет значение, когда ты берешься ему следовать. Но конкретный стандарт совершенно не обязывает тебя выбирать именно его. Например, XML совершенно не заставляет тебя использовать его для представления аргументов командной строки или конфигурационных файлов -- это уже выбор разработчика. Да и для интероперабильности XML далеко не единственный вариант, есть еще ASN1, XDR. Вот x509 сертификаты хранятся себе в ASN1 двоичном формате и ничего, практически все платформы умеют с ними работать.

... << RSDN@Home 1.1.4 stable rev. 510>>

	От:	GlebZ
	Дата:	09.09.05 16:03
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	09.09.05 16:30
Оценка:

	От:	Quintanar
	Дата:	09.09.05 17:11
	Оценка:	-1

	От:	GlebZ
	Дата:	09.09.05 17:21
	Оценка:

	От:	GlebZ
	Дата:	09.09.05 17:34
	Оценка:	23 (1)

От:	VladD2	www.nemerle.org
Дата:	09.09.05 22:00
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	09.09.05 22:35
Оценка:	+2

	От:	Павел Кузнецов
	Дата:	10.09.05 03:30
	Оценка: