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

ПК>Зачем эта морока? Только для того, чтоб удовлетворенно говорить, что конфиги у нас в XML?.. С использованием конфигов, основанных на регулярных грамматиках, жизнь становится намного проще: никакие парсеры не нужны, достаточно простых регулярных выражений. И пользователям, вынужденным править конфиги руками, легче объяснить, что там сделать нужно: никаких "заморочек" типа закрытия тегов и &.

Напомню, что в замен предлагается написать парсер собственного формата на С++. Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?

VladD2,

> ПК> Зачем эта морока? Только для того, чтоб удовлетворенно говорить, что конфиги у нас в XML?.. С использованием конфигов, основанных на регулярных грамматиках, жизнь становится намного проще: никакие парсеры не нужны, достаточно простых регулярных выражений. И пользователям, вынужденным править конфиги руками, легче объяснить, что там сделать нужно: никаких "заморочек" типа закрытия тегов и &.

> Напомню, что в замен предлагается написать парсер собственного формата на С++.

Необязательно. Можно использовать любой из миллиона уже существующих. Например, для формата .ini-файлов.

> Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?

Уже приводили use cases неоднократно: 1) нужно, чтоб пользователю было легко править конфигурационный файл "вручную"; 2) нужно, чтоб можно было легко работать с форматом конфигурационного файла из компонент, в которых нет готовой поддержки XML, но есть, например, поддержка регулярных выражений.

VladD2,

> ПК> А именно? На всякий случай: ActiveX и т.п. использовать нельзя: платформа не Windows.
>
> ДЛЛ или SO подойдет?

Вряд ли (см. ниже).

> Так вот я не знаю серверов не способных подключать ДЛЛ-и, и знаю реализации парсеров в виде ДЛЛ-ей.

Там два случая: один — серверный, второй — клиентский. Клиент кросс-платформенный, в нем используется реализация JavaScript из Mozilla (JSRef). Чтоб туда что-нибудь "прикрутить", нужно писать набор переходников в C++. Вопрос: зачем, если конфиги в стиле .ini-файлов прекрасно работают?

VladD2,

> ПК>Даже ini-файл проще, т.к. описывается регулярной грамматикой, и может разбираться регулярными выражениями.
>
> ini-файл не сильно проще.

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

> Вот возвратись на дцать постов назад и погляди на формат для котого привел парсер (простенький, в десять килобайт) eao197.

У eao197 свой use case, отличающийся от приведенного Мишей, тоже вполне жизненный.

К тому же, если посмотреть на дцать постов назад, то выяснится, что речь шла не о выборе между своим форматом и XML, а о решении некоторой задачи на C++. Вместо обсуждения решения автору начали "втирать", что ему решать эту задачу вообще не нужно.

VladD2,

> ПК>Use case был такой:
> ПК>

> ПК>наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file
> ПК>

> ПК>Соответственно, в этом контексте можно видеть, что предполагать наличие привычки править "руками" XML у пользователей продукта не вполне разумно.

> Развей свою мысль и объясни чем будет проще править самопальный конфиг сделанный под впечателением от Кюрла и т.п.

В данном случае речь идет о правке конфигов такого формата:

name1 = value1
name2 = value2

VladD2,

> M>Возвращясь к config файлам:
> M>У меня другие use cases <...>

> Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.

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

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

VD>Напомню, что в замен предлагается написать парсер собственного формата на С++.

Если говорить про меня, то предлагается использовать на C++ готовый парсер собственного формата.
Имхо, "написать" и "использовать" -- это две большие разницы.
Если тебе не нравится объем кода, в который это использование выливается, то пусть кто-нибудь попробует сделать на C++ разбор аналогичного XML-ного представления средствами того же TinyXML. Тогда и посмотрим.

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

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

E>> и я там отметился как противник XML-я. Не вообще, а против его повсеместного насаждения.

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

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

VD> и бороться за малопонятные велосипеды основания для применения нет.

Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?

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

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

ПК>>Даже ini-файл проще, т.к. описывается регулярной грамматикой, и может разбираться регулярными выражениями.

VD>ini-файл не сильно проще. Но тут о нем и речи не шло. Речь идет о сравнении дремучих сомаопальных велосипедах с конфигами на базе ХМЛ.

Влад, говоря про XML ты как бы автоматически подразумеваешь, что C++ код по извлечению данных из XML автоматически не может быть дремучим. Он просто обязательно будет компактным, понятным и сопровождаемым. Просто по определению.

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

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


M>>Возвращясь к config файлам:
M>>У меня другие use cases — когда наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file, он может полагаться только на то, что уже есть на компьютере пользователя — поэтому download современной IDE это не опция. Единственный встроенный XML editor, который я знаю — это редактор property files на Mac OS X. Он не поддерживает XML Schema etc.

M>>Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7&quot;. Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.

VD>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.

А почему бы и нет? Серьезно, почему нет?
Ведь если следовать твоей логике, то следовало бы на Коболе и Фортране до сих пор программировать. И вообще, зачем было C# делать, если за пять лет до него появилась почти такая же Java?

И разработчики Ruby такие же дремучие велосипедисты как я -- они почему-то YAML для конфигов используют, а не XML (у меня в Ruby 1.8.2 девятнадцать xml-файлов, три из них в тестах, остальные в примерах, и 2024 YAML файлов, которые используются инструментом ri (ruby index)). Да и вообще, взяли да язык свой придумали. Им, видимо, делать больше нечего было.

Кстати, я не изобретал синтаксис -- он уже был изобретен, причем даже не авторами Курла. Я просто сделал парсер этого формата (уже четыре года тому) и использую его для работы с конфигами и подобными вещами. Более того, когда в 2001 году я узнал про Курл, я написал одному из разработчиков Курла о том, что для конфигов Курл удобнее XML (на примере конфига для Java Web Application). И со мной согласились.

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

VD>Напомню, что в замен предлагается написать парсер собственного формата на С++. Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?

Тут правильно подметили, что даже при наличии готового XML-парсера, разбор конфигурационных файлов — не самая простая задача. Особенно если есть уровни вложенности. Вряд ли будет экономнее, чем то, что приведено в самописном парсере.

Для сравнения можно посмотреть в рефлекторе ту гору кода, которая пляшет вокруг довольно-таки строго размеченного app.config в .Net. И это при том, что формат app.config с его секциями и именами классов — далеко не user-friendly, скорее наоборот. На "человеческий" config вся эта белиберда мало похожа.

(Хотя я, как программист, вижу здесь весьма гибкое решение, но опять же — с т.з. программиста)

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

приведенный тобой фрагмент XML — это просто несбыточный идеал. На деле же, если XML генерить и парсить не "в ручную", а пользуясь стандартной XML сериализацией, или, того хуже app.config/web.config, то получаешь еще более нечитабельное преставление. В последнем случае вообще доступное пониманию лишь программиста.

E>

E><uint_data_class>
E>    <name value="smsg_2::smpp::a_smpp_transmitter_t::connection_state_monitor" />
E>    <priority value="5" />
E>    <font_size value="10" />
        
E>    <if>
E>        <equal_to value="st_not_connected" />
E>        <pixmap value="etc/gemont_1/img/xpm/red_cross_24x16.xpm" />
E>        <bkcolor value="magenta" />
E>    </if>
    
E>    <if>
E>        <equal_to value="st_connected" />
E>        <bkcolor value="blue" />
E>    </if>
E>    <if>
E>        <equal_to value="st_bind" />
E>        <pixmap value="etc/gemont_1/img/xpm/conn_exists_24x16.xpm" />
E>        <bkcolor    value="green" />
E>    </if>
E>    <if>
E>        <equal_to value="st_shutdown" />
E>        <bkcolor    value="yellow" />
E>    </if>
E></uint_data_class>
E>

E>Неужели это выглядит более читабельными и понятным?

Если бы все XML выглядели так же, то это было бы весьма неплохо.

Хотя, тут не поспоришь. На специализированном языке всегда можно проще и понятней написать.

Что касается степени благородства задачи "писания своих велосипедов" — это зависит от сравнительных размеров проектов: целевого и "велосипедного". Если относительный размер второго пренебрежимо мал, а удобства с т.з. первого на лицо, то тут даже и обсуждать нечего, просто делай свое дело хорошо.

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

E>Ну хотя бы то, что KDE -- это не GUI библиотека
E>А функциональность и сложность входящих в KDE продуктов на порядки превосходит Янус (ничего личного). Более того, компонент khtml из KDE был использован Apple для создания своего браузера Safari.

Кстати, Safari — это весЧь.
не думал, что бывают в природе такие приятные браузеры.

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

>> Напомню, что в замен предлагается написать парсер собственного формата на С++.

ПК>Необязательно. Можно использовать любой из миллиона уже существующих. Например, для формата .ini-файлов.

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

>> Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?

ПК>Уже приводили use cases неоднократно: 1) нужно, чтоб пользователю было легко править конфигурационный файл "вручную";

Значит нельзя? Жаль. А я бы хотел послушать про простоту правки вот этого:

{str_data_class    "smsg_2::smpp::a_smpp_transmitter_t::connection_state_monitor"
    {priority 5}
    {font_size 10}
    {if    {== "st_not_connected"}
        {pixmap    "etc/gemont_1/img/xpm/red_cross_24x16.xpm" }
        {bkcolor    "magenta"}
    }
    {if {== "st_connected"}
        {bkcolor    "blue"}
    }
    {if {== "st_bind"}
        {pixmap "etc/gemont_1/img/xpm/conn_exists_24x16.xpm" }
        {bkcolor    "green"}
    }
    {if {== "st_shutdown"}
        {bkcolor    "yellow"}
    }
}

{str_data_class    "smsg_2::smpp_smsc::a_smsc_t::m_connection_monitor_data"
    {priority 9}
    {font_size 11}
    {if    {== "st_not_bind"}
        {pixmap    "etc/gemont_1/img/xpm/red_cross_24x16.xpm" }
        {bkcolor    "magenta"}
        {sound    "etc/gemont_1/snd/wav/siren.wav"}
        {log_event {level "error"}
            {message "Нет соединения с SMSC"}}
    }
    {if {== "st_bind"}
        {pixmap "etc/gemont_1/img/xpm/conn_exists_24x16.xpm" }
        {bkcolor    "green"}
        {sound    "etc/gemont_1/snd/wav/online.wav"}
        {log_event {level "info"}
            {message "Есть соединение с SMSC"}}
    }
    {if {== "st_shutdown"}
        {bkcolor    "yellow"}
        {sound    "etc/gemont_1/snd/wav/tada.wav"}
    }
}

По сравлению с форматом основанным на ХМЛ-е.

ПК> 2) нужно, чтоб можно было легко работать с форматом конфигурационного файла из компонент, в которых нет готовой поддержки XML, но есть, например, поддержка регулярных выражений.

И как ты это собирашся обесечить для подобного формата? Я немного знаком с парсингом и уверяю тебя, что регексами это не отпарсить. Объем кода парсера написанного на С++ ты тоже можешь увидить понявшись на пару веток в верх.

Между тем надыбыть ХМЛ-парсер для любого языка на сегондя не составляет проблем.

ЗЫ

Тут кое-то може подтвержить, что я точно не являюсь фанатом ХМЛ, но для таких задач как конфиги — это почти идеальное решение.
В общем, твой спор

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

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

VD>>Напомню, что в замен предлагается написать парсер собственного формата на С++.

E>Если говорить про меня, то предлагается использовать на C++ готовый парсер собственного формата.

Готовым он стал через неделю траха (в лучшем случае). И кроме тебя никому ненужен. Так как люди не хотят изучать все велосипеды мира. Уж извини за прямоту.

E>Имхо, "написать" и "использовать" -- это две большие разницы.

Ага. По этому кое-что использует, а кое-кто пишет обвязочные фрэйморки.

E>Если тебе не нравится объем кода, в который это использование выливается,

Однозначно. Это половина кода полноценного редактора текста. У меря код конфирурировния занял намного меньше.

E> то пусть кто-нибудь попробует сделать на C++ разбор аналогичного XML-ного представления средствами того же TinyXML. Тогда и посмотрим.

А тут смотреть не на что. Готовый парсер всегда будет требовать меньше кодирования. Это аксиома.

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

>> ДЛЛ или SO подойдет?

ПК>Вряд ли (см. ниже).

>> Так вот я не знаю серверов не способных подключать ДЛЛ-и, и знаю реализации парсеров в виде ДЛЛ-ей.

ПК>Там два случая: один — серверный, второй — клиентский. Клиент кросс-платформенный, в нем используется реализация JavaScript из Mozilla (JSRef). Чтоб туда что-нибудь "прикрутить", нужно писать набор переходников в C++.

Не надо песен, а... Для той же мозилы и его скриптов уже давно есть ХМЛ-парсеры. Погляди тот же Кокон. Там ХМЛ из яваскриптов (именно мозильных) на право и на лево используется.

ПК> Вопрос: зачем, если конфиги в стиле .ini-файлов прекрасно работают?

Это очередная подмена понятий. Об ini-файлах речь никто не вел. Речь велась о клепании влосипедов. Короче, не хочу повторяться.

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

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

Ну, и что рукопашный парсер лучше?

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

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

Ты предпочиташь написать велосипд с самопальным форматом вместо того чтобы воспользоваться почти готовым решением. Это твоя огромная проблема. И ХМЛ тут всего лишь частный случай.

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

VD>> и бороться за малопонятные велосипеды основания для применения нет.

E>Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?

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

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

ПК>Сильно, т.к. для разбора можно использовать регулярные выражения.

Я об испоьзовании. ХМЛ-парсеры есть почти везде. Так что эта работа уже сделана. Еще раз повторюсь, что тут речь идет о создании велосипеда с оригинальным дизайном.

>> Вот возвратись на дцать постов назад и погляди на формат для котого привел парсер (простенький, в десять килобайт) eao197.

ПК>У eao197 свой use case, отличающийся от приведенного Мишей, тоже вполне жизненный.

Не стоит заговаривать зубы. Или обоснуй необходимость создания подобного велосипеда, или прекращай спорить ради спора. Разговор про инифайлы мне не интересен.

ПК>К тому же, если посмотреть на дцать постов назад, то выяснится, что речь шла не о выборе между своим форматом и XML, а о решении некоторой задачи на C++. Вместо обсуждения решения автору начали "втирать", что ему решать эту задачу вообще не нужно.

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

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

E>Влад, говоря про XML ты как бы автоматически подразумеваешь, что C++ код по извлечению данных из XML автоматически не может быть дремучим. Он просто обязательно будет компактным, понятным и сопровождаемым. Просто по определению.

Говоря про ХМЛ, я говорю об использовании (повтором и многокртаном) проверенных решений и надежных библиотек. Даже С++ становится не стольк ужасным выбором, если в нем есть отлаженная библиотека для решения конкретной задачи.

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