XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 05.09.05 07:17
Оценка: 6 (1)
Здравствуйте, Ka3a4oK, Вы писали:

KK>ИМХО неудачный пример. Если мне придется парсить что-либо, для чего можно составить регулярное вражение или КС-грамматику, я обязательно буду использовать средства автоматизации. Раньше это были bison/lex, сейчас еще хочу попробовать boost::spirit. Даже если мне нужно будет написать парсер для ini-файла, я также буду использовать средства автоматизации. Потому-что:

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

KK> Я считаю, кодирование парсеров вручную как раз и есть "ламерство". Данный подход не дает никаких преимуществ.



И что, для того, чтобы распарсить строки с значениями, разделенными запятыми, Вы пойдете изучать boost::spirit с его кучей шаблонов? Неделю ковыряться с ним вместо того, чтобы черкнуть пару вложенных циклов — IMHO верх идиотизма. Можно, конечно, и регулярные выражения использовать, только они будут все же медленнее работать,чем банальная пара циклов. Все эти решения — "из пушки по воробьям стрелять".


KK>И вообще, я не вижу ничего плохого в осмысленном использовании чужого опыта.

Чужой опыт подсказывает, что можно написать sscanf.

В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть:
1) стандартный виндозный формат и API для работы с ним
2) XML и куча парсеров к нему, на любой вкус.



KK> Я считаю, что главное для инженера(кем, по моему мнению, является программист)- это нахождение решения поставленой задачи. Чем лучше инженер, тем найденое решение оптимальней (по разным критериям — качество, стоимость, сроки).


Хороший программист, т.е. тот, который делает работу качественно и в срок, стоит дорого.





08.09.05 12:12: Ветка выделена из темы Программирование стало более высокоуровневым?
Автор: sch
Дата: 02.09.05
— AndrewVK
Re[3]: XML vs рукописный формат для конфигов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.09.05 07:33
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть:

AG>1) стандартный виндозный формат и API для работы с ним
AG>2) XML и куча парсеров к нему, на любой вкус.

XML и его парсеры -- это конечно хорошо, только когда из автоматически распарсеного DOM-дерева нужно будет преобразовывать данные в какое-то внутренне представление, то вот здесь главные неприятности и проявляются. Хорошо, если есть инструмент, который поддерживает отображение XML на внутренние типы данных. А вот если такого инструмента нет (как в случае с C++), то приходится писать кучу весьма некрасивого кода. И заниматься вещами, которые могут быть удобно встроены в какой-нибудь велосипед. Вот, например, хранятся в XML целочисленные значения. Получаешь ты их из DOM-а в виде строк, а дальше нужно в двоичное представление перевести. И начинается -- sscanf, istringstream, самописные преобразователи и пр. А добавим еще возможность сохранения значений в XML в разных системах счисления: 0x, 0, 0b -- еще веселее становится.

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

Disclamer: речь шла о C++, для которого нет стандартных средств отображения структур данных на C++.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 05.09.05 11:48
Оценка: 5 (2) +1 -1 :))) :))) :))
Здравствуйте, eao197, Вы писали:

E>А вот если такого инструмента нет (как в случае с C++), то приходится писать кучу весьма некрасивого кода.

Некрасивый код делается некрасивыми программистами. У красивых — все красиво

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

Значит вот что получается:
Если программист не знает что такое парсеры, то он его и не будет делать, так как не знает как.
Если программист не знает что такое парсеры, значит он не будет его писать и делать в нем ошибки.
Если программист не знает что такое парсеры, то он будет искать библиотеку работы с XML написанную людьми знающими что такое парсеры.
Если программист не знает что такое парсеры, то он будет подключать готовую отлаженную библиотеку, чем сократит время разработки.
Вывод:
Программист не знающий что такое парсеры — мечта каждого PM, и должен получать больше чем программист знающий что такое парсеры.
Не пора ли нам забыть, что такое парсеры?

С уважением, Gleb.
Re[5]: XML vs рукописный формат для конфигов
От: all-x Россия http://treedl.sf.net
Дата: 05.09.05 12:26
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


E>>А вот если такого инструмента нет (как в случае с C++), то приходится писать кучу весьма некрасивого кода.

GZ>Некрасивый код делается некрасивыми программистами. У красивых — все красиво

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

GZ>Значит вот что получается:
GZ>Если программист не знает что такое парсеры, то он его и не будет делать, так как не знает как.
GZ>Если программист не знает что такое парсеры, значит он не будет его писать и делать в нем ошибки.
GZ>Если программист не знает что такое парсеры, то он будет искать библиотеку работы с XML написанную людьми знающими что такое парсеры.
GZ>Если программист не знает что такое парсеры, то он будет подключать готовую отлаженную библиотеку, чем сократит время разработки.
GZ>Вывод:
GZ>Программист не знающий что такое парсеры — мечта каждого PM, и должен получать больше чем программист знающий что такое парсеры.
GZ>Не пора ли нам забыть, что такое парсеры?
GZ>

Как будто XML это панацея. Делает фактически только лексический анализ. А про DTD этот программист тоже ничего не знает? То есть, он DTD не напишет? А анализировать XML ручками будет? Получим те же овалы с другого ракурса...
Re[6]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 05.09.05 12:32
Оценка:
Здравствуйте, all-x, Вы писали:

AX>Как будто XML это панацея. Делает фактически только лексический анализ. А про DTD этот программист тоже ничего не знает? То есть, он DTD не напишет? А анализировать XML ручками будет? Получим те же овалы с другого ракурса...

DTD — это часть спецификации XML. Так что простенький семантический анализ там есть. Всякие XSD и DOM и еще куча, это уже другие спецификации. Посмотри спецификации на w3c.

С уважением, Gleb.
Re[3]: XML vs рукописный формат для конфигов
От: FDSC Россия consp11.github.io блог
Дата: 05.09.05 12:44
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

[[Какая-то ошибка была сначла! Сообщения не трансл.]]

KK>>> Я считаю, кодирование парсеров вручную как раз и есть "ламерство". Данный подход не дает никаких преимуществ.


Правильно.


AG>>И что, для того, чтобы распарсить строки с значениями, разделенными запятыми, Вы пойдете изучать boost::spirit с его кучей шаблонов? Неделю ковыряться с ним вместо того, чтобы черкнуть пару вложенных циклов — IMHO верх идиотизма. Можно, конечно, и регулярные выражения использовать, только они будут все же медленнее работать,чем банальная пара циклов. Все эти решения — "из пушки по воробьям стрелять".


Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.

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


KK>>>И вообще, я не вижу ничего плохого в осмысленном использовании чужого опыта.

AG>>Чужой опыт подсказывает, что можно написать sscanf.

А осмысленный чужой опыт подсказывает, что нельзя.

AG>>В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть:

AG>>1) стандартный виндозный формат и API для работы с ним
AG>>2) XML и куча парсеров к нему, на любой вкус.

Это то же внешние средства, просто менее мощные.

KK>>> Я считаю, что главное для инженера(кем, по моему мнению, является программист)- это нахождение решения поставленой задачи. Чем лучше инженер, тем найденое решение оптимальней (по разным критериям — качество, стоимость, сроки).


AG>>Хороший программист, т.е. тот, который делает работу качественно и в срок, стоит дорого.


Агитация халтуры и непрофессионализма! Давайте все будет хорошими программистами. Догда работадателям придётся нам зарплату повысить.
Re[7]: XML vs рукописный формат для конфигов
От: all-x Россия http://treedl.sf.net
Дата: 05.09.05 12:46
Оценка: 4 (1)
Здравствуйте, GlebZ, Вы писали:

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


AX>>Как будто XML это панацея. Делает фактически только лексический анализ. А про DTD этот программист тоже ничего не знает? То есть, он DTD не напишет? А анализировать XML ручками будет? Получим те же овалы с другого ракурса...

GZ>DTD — это часть спецификации XML. Так что простенький семантический анализ там есть. Всякие XSD и DOM и еще куча, это уже другие спецификации. Посмотри спецификации на w3c.

Получается, что вместо парсеров программист должен знать, как писать DTD. Бесплатных пирожных не бывает. А когда не хватит DTD, понадобятся и схемы (XSD) и то, что за ними (Схематрон, например). И не факт, что это легче писать/сопровождать, чем обычный парсер. И ошибок там можно наделать не меньше, а вот легче ли их выловить — я совсем не уверен.
Re[4]: XML vs рукописный формат для конфигов
От: WFrag США  
Дата: 05.09.05 14:18
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.


Тогда надо брать другой, более подходящий, инструмент, а не C++.
... << RSDN@Home 1.2.0 alpha rev. 521>>
Re[8]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 06.09.05 06:25
Оценка:
Здравствуйте, all-x, Вы писали:

AX>Получается, что вместо парсеров программист должен знать, как писать DTD.

Повторюсь. DTD — это часть спецификации XML. По моему там это называется директивами. Если мы не знаем директивы XML, значит мы не знаем XML. XML достаточно строгий формат.
AX>Бесплатных пирожных не бывает. А когда не хватит DTD, понадобятся и схемы (XSD) и то, что за ними (Схематрон, например). И не факт, что это легче писать/сопровождать, чем обычный парсер. И ошибок там можно наделать не меньше, а вот легче ли их выловить — я совсем не уверен.
Я уверен. Кроме синтаксиса есть семантика. Конечно, XML сделали по умному и можно дополнитильно семантику прямо парсером проверять. Но это надо реализовывать. И главное обязан знать. В случае использование готовых средств, такие кардинальные знания не нужны. Хочешь, пользуйся директивами, хочешь не пользуйся. Уверяю тебя, большинство пользователей xml о директивах и не догадываются.

С уважением, Gleb.
Re[9]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 06.09.05 08:28
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

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


AX>>Получается, что вместо парсеров программист должен знать, как писать DTD.

GZ>Повторюсь. DTD — это часть спецификации XML. По моему там это называется директивами. Если мы не знаем директивы XML, значит мы не знаем XML. XML достаточно строгий формат.

Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?

AX>>Бесплатных пирожных не бывает. А когда не хватит DTD, понадобятся и схемы (XSD) и то, что за ними (Схематрон, например). И не факт, что это легче писать/сопровождать, чем обычный парсер. И ошибок там можно наделать не меньше, а вот легче ли их выловить — я совсем не уверен.

GZ>Я уверен. Кроме синтаксиса есть семантика. Конечно, XML сделали по умному и можно дополнитильно семантику прямо парсером проверять. Но это надо реализовывать. И главное обязан знать. В случае использование готовых средств, такие кардинальные знания не нужны. Хочешь, пользуйся директивами, хочешь не пользуйся. Уверяю тебя, большинство пользователей xml о директивах и не догадываются.
GZ>С уважением, Gleb.

Зачем наживать себе геморой на задницу, если есть yacc я так и не понял.
Re[5]: XML vs рукописный формат для конфигов
От: FDSC Россия consp11.github.io блог
Дата: 06.09.05 09:04
Оценка:
Здравствуйте, WFrag, Вы писали:

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


FDS>>Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.


WF>Тогда надо брать другой, более подходящий, инструмент, а не C++.


Ну дак, если приложение уже на C++ пишется. Вот более подходящий инструмент и есть уже написанные библиотеки.
Re[4]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 06.09.05 09:46
Оценка:
Здравствуйте, FDSC, Вы писали:


AG>>>И что, для того, чтобы распарсить строки с значениями, разделенными запятыми, Вы пойдете изучать boost::spirit с его кучей шаблонов? Неделю ковыряться с ним вместо того, чтобы черкнуть пару вложенных циклов — IMHO верх идиотизма. Можно, конечно, и регулярные выражения использовать, только они будут все же медленнее работать,чем банальная пара циклов. Все эти решения — "из пушки по воробьям стрелять".


FDS>Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.


Улыбнуло Действительно, зачем мелочиться, лучше сразу закладываться на максимум — прикрутить лексический анализатор C++ — просто на будущее, если у заказчика требования поменяются.


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


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


KK>>>>И вообще, я не вижу ничего плохого в осмысленном использовании чужого опыта.

AG>>>Чужой опыт подсказывает, что можно написать sscanf.

FDS>А осмысленный чужой опыт подсказывает, что нельзя.


Это кто такой мыслитель ?


AG>>>В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть:

AG>>>1) стандартный виндозный формат и API для работы с ним
AG>>>2) XML и куча парсеров к нему, на любой вкус.

FDS>Это то же внешние средства, просто менее мощные.


Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для которого будет написан парсер на boost::spirit?



AG>>>Хороший программист, т.е. тот, который делает работу качественно и в срок, стоит дорого.


FDS>Агитация халтуры и непрофессионализма! Давайте все будет хорошими программистами. Догда работадателям придётся нам зарплату повысить.


Чего агитация? Чтобы считаться хорошим программистом, надо подтвердить это не словом, а делом. А считают себя самыми-самыми супер-пупер программистами все, кто пишет программы. Только не все ими являются в реальности.
Re[5]: XML vs рукописный формат для конфигов
От: Cyberax Марс  
Дата: 06.09.05 10:59
Оценка:
ArtemGorikov wrote:

> FDS>Сначала пара циклов, а потом приложение разрастётся и всё равно

> придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.
> Улыбнуло Действительно, зачем мелочиться, лучше сразу закладываться на
> максимум — прикрутить лексический анализатор C++ — просто на будущее,
> если у заказчика требования поменяются.

Нужно пркручивать не синтаксический анализатор С++, а _возможность_ его
потом прикрутить. То есть отделить слой чтения конфигов от остальной
программы, тогда тип неонки внутри конфигуратора не будет уже важен.

> FDS>Это то же внешние средства, просто *менее мощные*.

> Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для
> которого будет написан парсер на boost::spirit?

Да, так как он более примитивен

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[6]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 06.09.05 13:22
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Нужно пркручивать не синтаксический анализатор С++, а _возможность_ его

C>потом прикрутить. То есть отделить слой чтения конфигов от остальной
C>программы, тогда тип неонки внутри конфигуратора не будет уже важен.

Ну так кто же спорит? Я сказал, что прикручивать boost::spirit для чтения csv-шек глупо. То, что надо прятать реализацию от пользователей объекта, и так ясно.



>> FDS>Это то же внешние средства, просто *менее мощные*.

>> Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для
>> которого будет написан парсер на boost::spirit?

C>Да, так как он более примитивен


А что хранить-то надо? Для настроек XML подходит как нельзя лучше, незачем тут огород с велосипедами городить. Если как хранилище или БД то причем тогда ini- файл ?


C>--

C>С уважением,
C> Alex Besogonov (alexy@izh.com)
Re[10]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 06.09.05 13:48
Оценка: +1
Здравствуйте, Quintanar, Вы писали:

Q>Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?


Q>Зачем наживать себе геморой на задницу, если есть yacc я так и не понял.

Во первых не сказал бы что менее. Во вторых кроме знания yacc нужно изобретать язык. А в этом случае можно и хорошенько наглючить. К тому-же, насколько я помню, тот же yacc не очень любит unicode и тем более определение кодировки. Это уже нельзя построить xml парсер.

С уважением, Gleb.
Re[7]: XML vs рукописный формат для конфигов
От: Cyberax Марс  
Дата: 06.09.05 13:59
Оценка: +1
ArtemGorikov wrote:

> C>Нужно пркручивать не синтаксический анализатор С++, а _возможность_ его

> C>потом прикрутить. То есть отделить слой чтения конфигов от остальной
> C>программы, тогда тип неонки внутри конфигуратора не будет уже важен.
> Ну так кто же спорит? Я сказал, что прикручивать boost::spirit для
> чтения csv-шек глупо.

Как сказать, для _меня_ проще будет за пару минут набросать грамматику
на Spirit'е с семантическими действиями на Phoenix'е, которые сразу
формируют нужный массив результатов — так как я уже знаю как этим всем
пользоваться.

Для программиста Васи со второго курса — проще будет налабать "два
цикла". При этом у него, скорее всего, еще и не будет обрабатываться
unescapeing и не будут нормально обрабатываться ошибочные ситуации.

Кстати, корректный парсер для CSV занимает далеко не две строчки:
http://www.ioplex.com/~miallen/libmba/dl/src/csv.c

>>> FDS>Это то же внешние средства, просто *менее мощные*.

>>> Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для
>>> которого будет написан парсер на boost::spirit?
> C>Да, так как он более примитивен
> А что хранить-то надо? Для настроек XML подходит как нельзя лучше,
> незачем тут огород с велосипедами городить. Если как хранилище или БД
> то причем тогда ini- файл ?

Ну так вопрос был "что мощнее" Про лучше/хуже я ничего не говорил

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: XML vs рукописный формат для конфигов
От: all-x Россия http://treedl.sf.net
Дата: 06.09.05 14:10
Оценка: 1 (1) +1
Здравствуйте, GlebZ, Вы писали:

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


Q>>Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?


Q>>Зачем наживать себе геморой на задницу, если есть yacc я так и не понял.

GZ>Во первых не сказал бы что менее. Во вторых кроме знания yacc нужно изобретать язык. А в этом случае можно и хорошенько наглючить.

А в случае XML точно так же надо изобретать схему.

GZ> К тому-же, насколько я помню, тот же yacc не очень любит unicode и тем более определение кодировки. Это уже нельзя построить xml парсер.


Вообще говоря, генератору парсеров и не надо знать по unicode Он работает с потоком токенов.
Но на lex/yacc свет клином не сошелся, инструментов полно, ссылочек подкинуть?

Вообще, аргументы за и против изобретения собственных языков достаточно хорошо известны. Почитайте хоть Фаулера: http://www.martinfowler.com/articles/languageWorkbench.html#ProsAndConsOfLanguageOrientedProgramming

И разбираться, что именно применять, надо в каждом конкретном случае.
Насколько я помню, началось все с обсуждения, как парсить CSV файлы.
Во-первых, XML сразу отдыхает
Во-вторых, если бы знал подходящую проверенную библиотеку для чтения CSV — воспользовался бы ей.
В-третьих, если бы не знал готового решения, может и сделал все на коленке, но постарался бы сделать так,
чтобы в случае надобности можно было бы легко заменить этот кусок на использование тяжелой артиллерии.
Re[8]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 06.09.05 14:26
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Как сказать, для _меня_ проще будет за пару минут набросать грамматику

C>на Spirit'е с семантическими действиями на Phoenix'е, которые сразу
C>формируют нужный массив результатов — так как я уже знаю как этим всем
C>пользоваться
.

И все же, прикручивать гору кода из-за такой мелочи IMHO не стоит.


C>Для программиста Васи со второго курса — проще будет налабать "два

C>цикла". При этом у него, скорее всего, еще и не будет обрабатываться
C>unescapeing и не будут нормально обрабатываться ошибочные ситуации.

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


C>Кстати, корректный парсер для CSV занимает далеко не две строчки:

C>http://www.ioplex.com/~miallen/libmba/dl/src/csv.c

Думаю, использование spirit не освобождает от ответственности обрабатывать ошибочные ситуации.



>>>> FDS>Это то же внешние средства, просто *менее мощные*.

>>>> Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для
>>>> которого будет написан парсер на boost::spirit?
>> C>Да, так как он более примитивен
>> А что хранить-то надо? Для настроек XML подходит как нельзя лучше,
>> незачем тут огород с велосипедами городить. Если как хранилище или БД
>> то причем тогда ini- файл ?

C>Ну так вопрос был "что мощнее" Про лучше/хуже я ничего не говорил



Вспомнился анекдот про самые поездатые поезда в мире
Re[12]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 06.09.05 14:57
Оценка:
Здравствуйте, all-x, Вы писали:

AX>А в случае XML точно так же надо изобретать схему.

Не обязательно. Смотря что вы хотите от него.

AX>Вообще говоря, генератору парсеров и не надо знать по unicode Он работает с потоком токенов.

AX>Но на lex/yacc свет клином не сошелся, инструментов полно, ссылочек подкинуть?
Не надо. Сам юзаю ANTLR, хотя чаще пишу вручную. Но не для xml.

AX>Вообще, аргументы за и против изобретения собственных языков достаточно хорошо известны. Почитайте хоть Фаулера: http://www.martinfowler.com/articles/languageWorkbench.html#ProsAndConsOfLanguageOrientedProgramming

читал.

AX>И разбираться, что именно применять, надо в каждом конкретном случае.

Безусловно.
AX>Насколько я помню, началось все с обсуждения, как парсить CSV файлы.
Нет — обсуждение нужности парсеров.
AX>Во-вторых, если бы знал подходящую проверенную библиотеку для чтения CSV — воспользовался бы ей.
Excel
AX>В-третьих, если бы не знал готового решения, может и сделал все на коленке, но постарался бы сделать так,
AX>чтобы в случае надобности можно было бы легко заменить этот кусок на использование тяжелой артиллерии.
Отвечу также. Почитай хотя бы Фаулера.http://martinfowler.com/articles/designDead.html Делать только то что нужно на данный момент.

С уважением, Gleb.
Re[13]: XML vs рукописный формат для конфигов
От: all-x Россия http://treedl.sf.net
Дата: 06.09.05 15:31
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


AX>>А в случае XML точно так же надо изобретать схему.

GZ>Не обязательно. Смотря что вы хотите от него.

Обязательно. Её можно записывать явно или не записывать. Но в программе все равно будут
предположения о том, что может быть в XML — это и есть схема.

AX>>В-третьих, если бы не знал готового решения, может и сделал все на коленке, но постарался бы сделать так,

AX>>чтобы в случае надобности можно было бы легко заменить этот кусок на использование тяжелой артиллерии.
GZ>Отвечу также. Почитай хотя бы Фаулера.http://martinfowler.com/articles/designDead.html Делать только то что нужно на данный момент.

А вот это фигушки. Я с этим положением XP не согласен.
Не учитывается один важный фактор — сравнительная трудоемкость и производительность вариантов.
При прочих равных я выберу вариант, который легче развивать в предполагаемом направлении.
Лишние усилия тратить не буду. Если известно, что развитие не понадобится, тоже скорее всего не буду делать расширяемый вариант.
Но при прочих равных выберу то, что расширяется.
Re[14]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 06.09.05 15:48
Оценка:
Здравствуйте, all-x, Вы писали:

AX>Обязательно. Её можно записывать явно или не записывать. Но в программе все равно будут

AX>предположения о том, что может быть в XML — это и есть схема.
С такой точки зрения да. Но при этом не надо знать о правой и левой рекурсии, о различных конфликтах, и т.д. и т.п.

AX>А вот это фигушки. Я с этим положением XP не согласен.

AX>Не учитывается один важный фактор — сравнительная трудоемкость и производительность вариантов.
AX>При прочих равных я выберу вариант, который легче развивать в предполагаемом направлении.
AX>Лишние усилия тратить не буду. Если известно, что развитие не понадобится, тоже скорее всего не буду делать расширяемый вариант.
AX>Но при прочих равных выберу то, что расширяется.
Ваше право. Не хочется дополнительно затевать флейм.

С уважением, Gleb.
Re[9]: XML vs рукописный формат для конфигов
От: Cyberax Марс  
Дата: 06.09.05 16:07
Оценка: 4 (1) +2
ArtemGorikov wrote:

> C>Как сказать, для _меня_ проще будет за пару минут набросать грамматику

> C>на Spirit'е с семантическими действиями на Phoenix'е, которые сразу
> C>формируют нужный массив результатов — *так как я уже знаю как этим
> всем **
> C>пользоваться*.
> И все же, прикручивать гору кода из-за такой мелочи IMHO не стоит.

Почему "кучу"? Вот полный парсер:
    std::vector<std::string> vec_item;
    std::vector<std::string> vec_list;

    rule<> list_csv, list_csv_item;
    list_csv_item =
        !(
                confix_p('\"', *c_escape_ch_p, '\"')
            |   longest_d[real_p | int_p]
        );

    list_csv =
            list_p(
                list_csv_item[push_back_a(vec_item)],
                ','
            )[push_back_a(vec_list)]
        ;

    char const *plist_csv = "\"string\",\"string with an embedded \\\"\","
        "12345,0.12345e4,,2"; //В боевых условиях читается из файла.

    parse_info<> result = parse (plist_csv, list_csv);

Читается и понимается намного легче, чем код в csv.c. Библиотечный код
тут займет килобайт 5 максимум.

> C>*Для программиста Васи со второго курса* — проще будет налабать "два

> C>цикла". При этом у него, скорее всего, еще и не будет обрабатываться
> C>unescapeing и не будут нормально обрабатываться ошибочные ситуации.
> А кто здесь Вася?

Под "Васей" понимается просто малоопытный программист. Ничего личного

> Существуют определенные правила поведения в форуме. Так или иначе, не

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

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

> C>Кстати, корректный парсер для CSV занимает далеко не две строчки:

> C>http://www.ioplex.com/~miallen/libmba/dl/src/csv.c
> <http://www.ioplex.com/%7Emiallen/libmba/dl/src/csv.c&gt;
> Думаю, использование spirit не освобождает от ответственности
> обрабатывать ошибочные ситуации.

Ну так обработку ошибок намного проще делать с помощью парсеров.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[10]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.09.05 22:02
Оценка: +1
Здравствуйте, Quintanar, Вы писали:

Q>Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?


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

Ну, и чтобы пользователям не приходилось изучать новый формат на каждый чих.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: XML vs рукописный формат для конфигов
От: all-x Россия http://treedl.sf.net
Дата: 07.09.05 06:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Q>>Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?


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


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


То есть, вы тоже думаете, что если пользователь знает, что в XML бывают теги, атрибуты и прочее, что в стандарте написано,
так у него не будет проблем с созданием XML документов?
Re[12]: XML vs рукописный формат для конфигов
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.09.05 06:57
Оценка:
Здравствуйте, all-x, Вы писали:

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


AX>То есть, вы тоже думаете, что если пользователь знает, что в XML бывают теги, атрибуты и прочее, что в стандарте написано,

AX>так у него не будет проблем с созданием XML документов?

Можно отпасовать к дискуссии с Губановым, когда "вдруг" "неожиданно" выяснилось, что простота распознания отдельных элементов не означает простоты понимания всего текста.
... << RSDN@Home 1.1.4 stable rev. 510>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[10]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 07.09.05 07:35
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Почему "кучу"? Вот полный парсер:

C>
C>    std::vector<std::string> vec_item;
C>    std::vector<std::string> vec_list;

C>    rule<> list_csv, list_csv_item;
C>    list_csv_item =
C>        !(
C>                confix_p('\"', *c_escape_ch_p, '\"')
C>            |   longest_d[real_p | int_p]
C>        );

C>    list_csv =
C>            list_p(
C>                list_csv_item[push_back_a(vec_item)],
C>                ','
C>            )[push_back_a(vec_list)]
C>        ;

C>    char const *plist_csv = "\"string\",\"string with an embedded \\\"\","
C>        "12345,0.12345e4,,2"; //В боевых условиях читается из файла.

C>    parse_info<> result = parse (plist_csv, list_csv);
C>

C>Читается и понимается намного легче, чем код в csv.c. Библиотечный код
C>тут займет килобайт 5 максимум.


Это какие-то шаманские танцы с бубном. То, что код короче, еще не означает, что он легче в понимании для людей, не использовавших раньше spirit. Кстати, IMHO лучше явно прописывать namespace spirit, чтобы хоть знать, откуда взялись rule<> и parse_info<>.

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


C>Фича в том, что код, использующий документированые внешние

C>библиотеки поддерживается намного проще кода с кучей велосипедов. Хотя
C>бы потому, что в случае какой-нибудь странной ошибки очень часто ее
C>причину и методы решения можно найти в списках рассылки/форумах
C>пользователей этой библиотеки.

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


C>Ну так обработку ошибок намного проще делать с помощью парсеров.

Это уже интересно А какие в Вашем примере в случае CSV встроенные средства проверки, ну скажем, что количество столбцов в строке правильное? И какая, Вы считаете, будет скорость у Вашего парсера на больших файлах, когда он будет копировать тучу строк в вектор с std::string, который, кстати, не знает про подсчет ссылок и честно копирует все содержимое буфера при каждой операции присваивания? А если файл попадется размером под 7-10 гиг, что тут Ваш парсер скажет?


P.S. Я писал в свое время читалку текстовых файлов любого размера, с любыми разделителями столбцов, всевозможными проверками, реверсивным порядком строк и т.д. и знаю, о чем говорю. Ваш парсер csv-шек на самом деле не больше, чем академически очень интересная, но на практике бесполезная вещь.
Re[11]: XML vs рукописный формат для конфигов
От: Cyberax Марс  
Дата: 07.09.05 08:26
Оценка:
ArtemGorikov wrote:

> C>Читается и понимается намного легче, чем код в csv.c. Библиотечный код

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

Да. А код на С++ легче понимается людьми, знающими С++. У меня в
команде, например, все понимают Spirit.

> Вот Вы уже использовали spirit там, где он действительно необходим, и

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

Я этот код написал за минуту — код из csv.c я буду повторять час.
Разница есть?

> C>Фича в том, что код, использующий *документированые* внешние

> C>библиотеки поддерживается намного проще кода с кучей велосипедов. Хотя
> C>бы потому, что в случае какой-нибудь странной ошибки очень часто ее
> C>причину и методы решения можно найти в списках рассылки/форумах
> C>пользователей этой библиотеки.
> Вот вот, в случае ошибки в либе Вы предлагаете искать ее решение на
> форумах в инете, вместо того чтобы пофиксить ее самому за пару секунд.

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

> C>Ну так обработку ошибок намного проще делать с помощью парсеров.

> Это уже интересно А какие в Вашем примере в случае CSV встроенные
> средства проверки, ну скажем, что количество столбцов в строке правильное?

А у меня ее нет Такой CSV с переменным числом колонок.

> И какая, Вы считаете, будет скорость у Вашего парсера на больших

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

Одно копирование на строку — не такая большая вещь.

> А если файл попадется размером под 7-10 гиг, что тут Ваш парсер скажет?


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

> P.S. Я писал в свое время читалку текстовых файлов любого размера, с

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

И что? И сколько вы на это времени потратили?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 07.09.05 08:30
Оценка: 1 (1) +2 -2
Здравствуйте, VladD2, Вы писали:

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


Q>>Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?


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


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


Я, как пользователь, которому приходилось сталкиваться с форматом данных в XML, с удовольствием посылаю на ... всех, кто таким образом пытается проявить заботу о пользователях. XML ничего не дает, формат изучать все равно надо, только он к тому же еще загажен XML'ем.
Re[12]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 07.09.05 09:27
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Да. А код на С++ легче понимается людьми, знающими С++. У меня в

C>команде, например, все понимают Spirit.

Тяжело им наверное


>> Вот Вы уже использовали spirit там, где он действительно необходим, и

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

C>Я этот код написал за минуту — код из csv.c я буду повторять час.

C>Разница есть?

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


C>А вот фига за "пару секунд". При большой концентрации велосипедов время

C>поиска тривиальных ошибок может занимать целые часы и дни.

А при большой концентрации либ ? Просто IMHO spirit — не самое оптимальное средство чтения csv-шек.


>> C>Ну так обработку ошибок намного проще делать с помощью парсеров.

>> Это уже интересно А какие в Вашем примере в случае CSV встроенные
>> средства проверки, ну скажем, что количество столбцов в строке правильное?

C>А у меня ее нет Такой CSV с переменным числом колонок.


Ну тогда конечно. Но вообще-то в csv обычно хранятся табличные данные.


>> И какая, Вы считаете, будет скорость у Вашего парсера на больших

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

C>Одно копирование на строку — не такая большая вещь.


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

>> А если файл попадется размером под 7-10 гиг, что тут Ваш парсер скажет?


C>А ничего не скажет. Для таких размеров я буду использовать не вектор

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

Напоминаю, что предел 32-битной адресации 2^32 составляет 4 гига. На практике, предел размера проекции файла в память в Win NT составил около 500 метров. В 9x все еще хуже.
Вы в своем примере на входе парсера передали строку с завершающим нулем. Т.е. даже проекция не катит, т.к. никто не гарантировал, что в конце файла будет ноль.


>> P.S. Я писал в свое время читалку текстовых файлов любого размера, с ...


C>И что? И сколько вы на это времени потратили?


Много. Но этот модуль много чего может. До него в фирме было написано 4 таких читалки, большинство в качестве тестовых заданий, тяп-ляп за минуту. У них всех была одинаковая проблема: читали только заранее им известный формат, последовательность столбцов, безбожно тормозили. На файлах размером ~100 метров и выше падали где-то посередине конвертации — и это после всех оптимизаций, типа "круче только яйца".

Так что когда нужно действительно читать любые файлы, а не только специально приготовленные и "причесанные" под твой парсер, стандартные и ориентированные под определенный формат файла решения не катят .
Re[11]: XML vs рукописный формат для конфигов
От: FDSC Россия consp11.github.io блог
Дата: 07.09.05 11:07
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Вот Вы уже использовали spirit там, где он действительно необходим, и теперь его применяете везде. А в случае, когда стоит выбор — сделать все отлаженным способом или убить время на разбор парсеров, тока чтобы сделать все "красиво" — чистой воды выпендреж и "рисование".


Красиво ещё и оптимально. Практически любой красивый код экономически более выгоден.


А "сделать все отлаженным способом" это не то же самое, что "убить время на разбор парсеров". Для некоторых одно и то же. Очевидно.
Re[12]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 07.09.05 11:43
Оценка: :)
Здравствуйте, FDSC, Вы писали:


FDS>Красиво ещё и оптимально. Практически любой красивый код экономически более выгоден.


Точно. Можно проводить выставки "Абстракционизм в неомодернистском искусстве кодинга" Ездить с экспозицией по Европе и Штатам, деньгу зашибать.

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


FDS>А "сделать все отлаженным способом" это не то же самое, что "убить время на разбор парсеров". Для некоторых одно и то же. Очевидно.


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

Просто для каждой задачи существует свой инструмент, незачем отверткой забивать гвозди.
Re[13]: XML vs рукописный формат для конфигов
От: FDSC Россия consp11.github.io блог
Дата: 07.09.05 11:59
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

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



FDS>>Красиво ещё и оптимально. Практически любой красивый код экономически более выгоден.


AG>Точно. Можно проводить выставки "Абстракционизм в неомодернистском искусстве кодинга" Ездить с экспозицией по Европе и Штатам, деньгу зашибать.


AG>Решение оптимально не в смысле меньшего количества строк, а в смысле скорости работы и реализации всего необходимого функционала.


Красиво ещё не значит, с меньшим числом строк кода.


FDS>>А "сделать все отлаженным способом" это не то же самое, что "убить время на разбор парсеров". Для некоторых одно и то же. Очевидно.


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

AG>Убить время на разбор парсеров означает пытаться прикрутить к чему ни попадя парсер на spirit, просто потому что недавно узнал о его существовании.

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


AG>Просто для каждой задачи существует свой инструмент, незачем отверткой забивать гвозди.


Именно. Хоть с этим я согласен!
Re[13]: XML vs рукописный формат для конфигов
От: Cyberax Марс  
Дата: 07.09.05 12:20
Оценка: +1
ArtemGorikov wrote:

> C>Да. А код на С++ легче понимается людьми, знающими С++. У меня в

> C>команде, например, все понимают Spirit.
> Тяжело им наверное

Тяжело, но совсем не от знания Spirit'а.

> C>Я этот код написал за минуту — код из csv.c я буду повторять час.

> C>Разница есть?
> Да что Вы все сишный пример приводите?

Это провереный и протестированый кусок кода — любой другой читатель csv
будет выглядеть примерно так же.

> C>А вот фига за "пару секунд". При большой концентрации велосипедов время

> C>поиска тривиальных ошибок может занимать целые часы и дни.
> А при большой концентрации либ ?

У либ есть волшебное свойство — они используются многими.

> Просто IMHO spirit — не самое оптимальное средство чтения csv-шек.


Да, но если надо решить побочную задачу в виде чтения csv-шек —
то spirit как раз идеально подходит (если его знать, разумеется).


> C>А у меня ее нет Такой CSV с переменным числом колонок.

> Ну тогда конечно. Но вообще-то в csv обычно хранятся *табличные* данные.

Ну да, можно изменить и на таблицу — мне это пару операторов поменять.

> C>Одно копирование на строку — не такая большая вещь.

> Умноженное на количество строк в файле, количество столбцов и
> количество изменений размера вектора, это очень большая вещь, я даже
> не побоюсь этого слова *тормоз*

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

> C>А ничего не скажет. Для таких размеров я буду использовать не вектор

> C>строк, а что-нибудь другое (например, буду скармливать данные нужному
> C>блоку сразу же после чтения).
> Напоминаю, что предел 32-битной адресации 2^32 составляет *4* гига. На
> практике, предел размера проекции файла в память в Win NT составил
> около 500 метров. В 9x все еще хуже.
> Вы в своем примере на входе парсера передали строку с завершающим
> нулем. Т.е. даже проекция не катит, т.к. никто не гарантировал, что в
> конце файла будет ноль.

А вот это как раз пример гибкости моего решения — я просто НЕ буду
читать файл в память, а буду использовать Spirit в потоковом режиме. То
есть просто скормлю ему fstream в качестве ввода — потребует изменения
двух строчек кода (ну ладно — четырех, с учетом обработки ошибки
открытия файла).

Более того, если мне потребуется сделать разбор CSV приходящего из сети
— то я просто напишу (точнее возьму из Boost File Vault) свою реализацию
итераторов поверх сокетов. И тоже все будет работать.

А вот велосипеду, скорее всего, придется переписываться.

> Так что когда нужно действительно читать любые файлы, а не только

> специально приготовленные и "причесанные" под твой парсер, стандартные
> и ориентированные под определенный формат файла решения не катят .

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0 beta
Sapienti sat!
Re[14]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 07.09.05 12:21
Оценка: +1
Здравствуйте, FDSC, Вы писали:


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

AG>>Убить время на разбор парсеров означает пытаться прикрутить к чему ни попадя парсер на spirit, просто потому что недавно узнал о его существовании.

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


Странно. Почему ты решил, что я не хочу изучать какой-то класс? Да может, я сам его и написал когда-то, или уже пользовался им в похожих задачах. Я вообще никогда ничего сам не пишу, если оно уже написано и полностью удовлетворяет условиям задачи. Я же был против использования spirit в данном конкретном случае чтения csv-шек, а вот когда он будет наиболее оптимальным решением, с радостью его использую. Только не было пока у меня таких задач. Для XML есть другие, заточенные под него, парсеры, более быстрые и удобные. Если нужен скрипт, я использую MS скриптовую машину. В случае, когда нужен интерпретатор/компилятор еще какого языка, так у них уже есть свой синтаксический анализатор.

AG>>Просто для каждой задачи существует свой инструмент, незачем отверткой забивать гвозди.

FDS>Именно. Хоть с этим я согласен!
Использовать spirit для csv или XML — и есть "отверткой забивать гвозди"
Re[12]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.09.05 12:36
Оценка:
Здравствуйте, all-x, Вы писали:

AX>То есть, вы тоже думаете, что если пользователь знает, что в XML бывают теги, атрибуты и прочее, что в стандарте написано,

AX>так у него не будет проблем с созданием XML документов?

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

Пара примеров... Для оприсания синтаксиса языка лучше использовать EBNF. Для кофигурирования клавиатурных сокращений в неком приложении лучше воспользоваться ХМЛ-ем. (ИМХО естественно)
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.09.05 12:36
Оценка: +1
Здравствуйте, Quintanar, Вы писали:

Q>Я, как пользователь, которому приходилось сталкиваться с форматом данных в XML, с удовольствием посылаю на ... всех, кто таким образом пытается проявить заботу о пользователях. XML ничего не дает, формат изучать все равно надо, только он к тому же еще загажен XML'ем.


Вот тебе протой пример. В Rsdn.Editor нужно настраивать клавиатурные сокращения. Это сделано через ХМЛ-файл. Вот как он выглядит:
<?xml version="1.0" encoding="utf-8" ?>
<Shortcuts>
    <!-- Навигация по тексту -->
    <Shortcut Key="Up"                      Action="CaretViewLineUp"/>
    <Shortcut Key="Down"                    Action="CaretViewLineDown"/>
    <Shortcut Key="Shift | Up"              Action="CaretViewLineUpExtend"/>
    <Shortcut Key="Shift | Down"            Action="CaretViewLineDownExtend"/>
    <Shortcut Key="Home"                    Action="CaretViewLineHome"/>
    <Shortcut Key="End"                     Action="CaretViewLineEnd"/>
    <Shortcut Key="Shift | Home"            Action="CaretViewLineHomeExtend"/>
    <Shortcut Key="Shift | End"             Action="CaretViewLineEndExtend"/>
    <Shortcut Key="Left"                    Action="CaretLeft"/>
    <Shortcut Key="Control | Left"          Action="CaretWordLeft"/>
    <Shortcut Key="Control | Right"         Action="CaretWordRight"/>
    <Shortcut Key="Shift | Control | Left"  Action="CaretWordLeftExtend"/>
    <Shortcut Key="Shift | Control | Right" Action="CaretWordRightExtend"/>
    <Shortcut Key="Shift | Left"            Action="CaretLeftExtend"/>
    <Shortcut Key="Shift | Right"           Action="CaretRightExtend"/>
    <Shortcut Key="Right"                   Action="CaretRight"/>
    <Shortcut Key="PageUp"                  Action="PageUp"/>
    <Shortcut Key="PageDown"                Action="PageDowd"/>
    <Shortcut Key="Control | Home"          Action="CaretDocumentHome"/>
    <Shortcut Key="Control | End"           Action="CaretDocumentEnd"/>
    <Shortcut Key="Shift | Control | Home"  Action="CaretDocumentHomeExtend"/>
    <Shortcut Key="Shift | Control | End"   Action="CaretDocumentEndExtend"/>
    <Shortcut Key="Control | A"             Action="SelectAll"/>
    <!-- Клипборд -->
    <Shortcut Key="Control | C"             Action="Copy"/>
    <Shortcut Key="Control | Insert"        Action="Copy"/>
    <Shortcut Key="Control | V"             Action="Paste"/>
    <Shortcut Key="Shift | Insert"          Action="Paste"/>
    <Shortcut Key="Control | X"             Action="Cut"/>
    <Shortcut Key="Shift | Delete"          Action="Cut"/>
    <!-- Редактирование -->
    <Shortcut Key="Delete"                  Action="Delete"/>
    <Shortcut Key="Back"                    Action="DeleteBack"/>
    <Shortcut Key="Control | Z"             Action="Undo"/>
    <Shortcut Key="Alt | Back"              Action="Undo"/>
    <Shortcut Key="Control | Y"             Action="Redo"/>
    <Shortcut Key="Alt | Shift | Back"      Action="Redo"/>
    <!-- Отладка -->
    <Shortcut Key="F5"                      Action="Test1"/>
    <Shortcut Key="F6"                      Action="PaintTest"/>
</Shortcuts>


Препдложи, плиз более подходящий формат, и попробуй обосновать этот выбор. Потом опиши что нужно предпринять для реализации твоего решения.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: XML vs рукописный формат для конфигов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.09.05 13:05
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

VD>Вот тебе протой пример. В Rsdn.Editor нужно настраивать клавиатурные сокращения. Это сделано через ХМЛ-файл. Вот как он выглядит:

VD>
VD><?xml version="1.0" encoding="utf-8" ?>
VD><Shortcuts>
VD>    <!-- Навигация по тексту -->
VD>    ...
VD>    <Shortcut Key="Shift | Up"              Action="CaretViewLineUpExtend"/>
VD>    <Shortcut Key="Shift | Down"            Action="CaretViewLineDownExtend"/>
VD>    ...
VD></Shortcuts>
VD>


На самом деле, имхо, здесь два языка: первый -- XML со своими заморочками, а второй -- возможность опеределять комбинацию клавиш в одном атрибуте Key, разделяя названия с помощью вертикальной черты. Причем никакой XML редактор не оградит незадачливого пользователя от возможности написать Key="Shift+Up" или Key="Shift,Up" или Key="Shift-Up".

Уж если использовать XML для описания всего языка, то нужно было бы что-то вроде:
<?xml version="1.0" encoding="utf-8" ?>
<Shortcuts>
<Shortcut Key="Up" Shift="on"                Action="CaretViewLineUpExtend" />
<Shortcut Key="Down" Shift="on"              Action="CaretViewLineDownExtend" />
<Shortcut Key="Back" Alt="on" Shift="on"     Action="Redo"/>
</Shortcuts>


или даже
<?xml version="1.0" encoding="utf-8" ?>
<Shortcuts>
<Shortcut>
    <Key>Up</Key>
    <Shift/>
    <Action>CaretViewLineUpExtend</Action>
</Shortcut>
<Shortcut>
    <Key>Down</Key>
    <Shift/>
    <Action>CaretViewLineDownExtend</Action>
</Shortcut>
<Shortcut>
    <Key>Back</Key>
    <Alt/>
    <Shift/>    
    <Action>Redo</Action>
</Shortcut>
</Shortcuts>


Но так, имхо, уже гораздо менее читабельно.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 07.09.05 13:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>ArtemGorikov wrote:


>> C>Да. А код на С++ легче понимается людьми, знающими С++. У меня в

>> C>команде, например, все понимают Spirit.
>> Тяжело им наверное

C>Тяжело, но совсем не от знания Spirit'а.

+


C>У либ есть волшебное свойство — они используются многими.

+

>> Просто IMHO spirit — не самое оптимальное средство чтения csv-шек.


C>Да, но если надо решить побочную задачу в виде чтения csv-шек —

C>то spirit как раз идеально подходит (если его знать, разумеется).
Для побочной задачи подходит, а вот как насчет основной?


>> C>А у меня ее нет Такой CSV с переменным числом колонок.

>> Ну тогда конечно. Но вообще-то в csv обычно хранятся *табличные* данные.

C>Ну да, можно изменить и на таблицу — мне это пару операторов поменять.

+

>> C>Одно копирование на строку — не такая большая вещь.

>> Умноженное на количество строк в файле, количество столбцов и
>> количество изменений размера вектора, это очень большая вещь, я даже
>> не побоюсь этого слова *тормоз*

C>Нет, тут накладные расходы на чтение файла больше времени займут.

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


C>Более того, если мне потребуется сделать разбор CSV приходящего из сети

C>- то я просто напишу (точнее возьму из Boost File Vault) свою реализацию
C>итераторов поверх сокетов. И тоже все будет работать.
Да итераторы вообще рулез!


C>А вот велосипеду, скорее всего, придется переписываться.

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


C>Я уже показал, как я могу быстро и непринужденно модифицировать свое

C>решение под изменяющиеся требования.

Требования не просто изменяются, они добавляются. Как, например, сделать на spirit так, чтобы вначале файла был заголовок (нулевая запись), а потом записи читались наоборот снизу, т.е. 1 запись уже последняя строчка в файле?
Я так понимаю, делается велосипед с итераторами, а потом к нему проволокой прикручивается spirit, потому что разбить строку на столбцы можно вообще без него. Итого на задачу, решаемую спиритом, остается .001% от всей сложности системы, и он легко заменяется на один цикл. Точнее даже не так: спирит заполняет вектор, потом по нему в цикле производятся какие-то действия, а так остается цикл, в нем с каждой колонкой выполняются действия. Т.е. спирит просто выбрасывается за ненадобностью.
Re[15]: XML vs рукописный формат для конфигов
От: Cyberax Марс  
Дата: 07.09.05 13:23
Оценка:
ArtemGorikov wrote:

> C>Да, но если надо решить *побочную* задачу в виде чтения csv-шек —

> C>то spirit как раз идеально подходит (если его знать, разумеется).
> Для побочной задачи подходит, а вот как насчет основной?

А это уже надо смотреть и считать. Например, что важнее: максимальное
быстродействие, потребление памяти или расширяемость? Смотреть на
существующие решения, искать инструменты (например, вместо Spirit'а
взять ANT LR или старый добрый lex+yacc).

> C>Нет, тут накладные расходы на чтение файла больше времени займут.

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

Если правильно писать — не больше одного копирования. А если писать еще
правильнее, и использовать строчки (flex_string'например) со счетчиком
ссылок — вообще копирований не нужно будет.

> C>А вот велосипеду, скорее всего, придется переписываться.

> Велосипед можно сделать на итераторах, чтобы не было мучительно больно
> потом переписывать .
> И вообще "велосипед" это или нет, зависит от точки зрения: что для
> создателя — велосипед, для юзеров — проверенная либа

Ну да, но вопрос "писать свою _библиотеку_, или взять готовую" вообще
почти всегда разрешается в пользу готовой либы.

> C>Я уже показал, как я могу быстро и непринужденно модифицировать свое

> C>решение под изменяющиеся требования.
> Требования не просто изменяются, они добавляются. Как, например,
> сделать на spirit так, чтобы вначале файла был заголовок (нулевая запись)

Чуть-чуть изменить грамматику, ну примерно так:
rule<> header=....; //Правило для заголовка
rule<> csv_file=header << ...; //И так далее


> а потом записи читались наоборот снизу, т.е. 1 запись уже последняя

> строчка в файле?

Использовать деку вместо вектора и пихать строчки не push_back'ом,
push_front'ом.

> Я так понимаю, делается велосипед с итераторами, а потом к нему

> проволокой прикручивается spirit, потому что разбить строку на столбцы
> можно вообще без него.

Зачем? Если потребуется что-то уж очень нестандартное — то просто
пишется custom action, который вставляется как обработчик определенной
строки. Более того, в Spirit'е есть еще другой монстр под названием
Phoenix. В нем можно писать вот так:
    int init[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
    vector<int> c(init, init + 10);
    typedef vector<int>::iterator iterator;

    for_each(c.begin(), c.end(),
        locals<int, char const*>(0, "...That's all\n")
        [
            for_(loc1 = 0, loc1 < arg1, ++loc1)
            [
                cout << loc1 << ", "
            ],
            cout << loc2
        ]
    );

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

> Итого на задачу, решаемую спиритом, остается .001% от всей сложности

> системы, и он легко заменяется на один цикл.

Нет, скорее наоборот — 0.001% будут не spirit-ным кодом.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0 beta
Sapienti sat!
Re[13]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 07.09.05 15:05
Оценка: 2 (2) +3 -1
VladD2,

> Вот тебе протой пример. В Rsdn.Editor нужно настраивать клавиатурные сокращения. Это сделано через ХМЛ-файл. Вот как он выглядит:

>
> <?xml version="1.0" encoding="utf-8" ?>
> <Shortcuts>
>     <!-- Навигация по тексту -->
>     <Shortcut Key="Up"                      Action="CaretViewLineUp"/>
>     <Shortcut Key="Down"                    Action="CaretViewLineDown"/>
>     <Shortcut Key="Shift | Up"              Action="CaretViewLineUpExtend"/>
>     <Shortcut Key="Shift | Down"            Action="CaretViewLineDownExtend"/>
>     <Shortcut Key="Home"                    Action="CaretViewLineHome"/>
>     <Shortcut Key="End"                     Action="CaretViewLineEnd"/>
>     <Shortcut Key="Shift | Home"            Action="CaretViewLineHomeExtend"/>
>     <Shortcut Key="Shift | End"             Action="CaretViewLineEndExtend"/>
>     <Shortcut Key="Left"                    Action="CaretLeft"/>
>     <Shortcut Key="Control | Left"          Action="CaretWordLeft"/>
>     <Shortcut Key="Control | Right"         Action="CaretWordRight"/>
>     <Shortcut Key="Shift | Control | Left"  Action="CaretWordLeftExtend"/>
>     <Shortcut Key="Shift | Control | Right" Action="CaretWordRightExtend"/>
>     <Shortcut Key="Shift | Left"            Action="CaretLeftExtend"/>
>     <Shortcut Key="Shift | Right"           Action="CaretRightExtend"/>
>     <Shortcut Key="Right"                   Action="CaretRight"/>
>     <Shortcut Key="PageUp"                  Action="PageUp"/>
>     <Shortcut Key="PageDown"                Action="PageDowd"/>
>     <Shortcut Key="Control | Home"          Action="CaretDocumentHome"/>
>     <Shortcut Key="Control | End"           Action="CaretDocumentEnd"/>
>     <Shortcut Key="Shift | Control | Home"  Action="CaretDocumentHomeExtend"/>
>     <Shortcut Key="Shift | Control | End"   Action="CaretDocumentEndExtend"/>
>     <Shortcut Key="Control | A"             Action="SelectAll"/>
>     <!-- Клипборд -->
>     <Shortcut Key="Control | C"             Action="Copy"/>
>     <Shortcut Key="Control | Insert"        Action="Copy"/>
>     <Shortcut Key="Control | V"             Action="Paste"/>
>     <Shortcut Key="Shift | Insert"          Action="Paste"/>
>     <Shortcut Key="Control | X"             Action="Cut"/>
>     <Shortcut Key="Shift | Delete"          Action="Cut"/>
>     <!-- Редактирование -->
>     <Shortcut Key="Delete"                  Action="Delete"/>
>     <Shortcut Key="Back"                    Action="DeleteBack"/>
>     <Shortcut Key="Control | Z"             Action="Undo"/>
>     <Shortcut Key="Alt | Back"              Action="Undo"/>
>     <Shortcut Key="Control | Y"             Action="Redo"/>
>     <Shortcut Key="Alt | Shift | Back"      Action="Redo"/>
>     <!-- Отладка -->
>     <Shortcut Key="F5"                      Action="Test1"/>
>     <Shortcut Key="F6"                      Action="PaintTest"/>
> </Shortcuts>
>

> Препдложи, плиз более подходящий формат,

Opera Preferences version 2.0
; Keyboard input specification file for Opera 7.0
; This file is stored in UTF-8 encoding

[Version]
File Version=1

[Info]
Name=Opera Standard
Description=Opera Standard Keyboard setup
Author=Opera Software ASA
Version=1

[Application]
Platform Windows-Unix-QNX, h ctrl    = Hide Opera
ContextMenu                          = Show context menu
Enter ctrl                           = Wand
Platform Mac, Enter meta             = Wand
c ctrl                               = Copy
c ctrl shift                         = Copy to note
v ctrl                               = Paste
v ctrl shift                         = Paste to note
d ctrl                               = Paste and go
d ctrl shift                         = Paste and go
x ctrl                               = Cut
z ctrl                               = Undo
y ctrl                               = Redo
z ctrl shift                         = Redo
y ctrl shift                         = Undo
a ctrl                               = Select all
u ctrl                               = Clear
Ins                                  = Toggle overstrike
Del                                  = Delete
Platform Windows-Unix-QNX, Backspace = Backspace | Back
Platform Mac, Backspace              = Backspace | Delete | Back


> и попробуй обосновать этот выбор.


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

> Потом опиши что нужно предпринять для реализации твоего решения.


Не больше, чем в случае использования XML.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[13]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 07.09.05 15:45
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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


Тебе описали уже более подходящий формат. Я имел дело с XML языками. Поверь мне, даже Oberon лучше XML языка.
Re[14]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 07.09.05 16:13
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:


ПК>
ПК>Opera Preferences version 2.0
ПК>; Keyboard input specification file for Opera 7.0
ПК>; This file is stored in UTF-8 encoding

ПК>[Version]
ПК>File Version=1

ПК>[Info]
ПК>Name=Opera Standard
ПК>Description=Opera Standard Keyboard setup
ПК>Author=Opera Software ASA
ПК>Version=1

ПК>[Application]
ПК>Platform Windows-Unix-QNX, h ctrl    = Hide Opera
ПК>ContextMenu                          = Show context menu
ПК>Enter ctrl                           = Wand
ПК>Platform Mac, Enter meta             = Wand
ПК>c ctrl                               = Copy
ПК>c ctrl shift                         = Copy to note
ПК>v ctrl                               = Paste
ПК>v ctrl shift                         = Paste to note
ПК>d ctrl                               = Paste and go
ПК>d ctrl shift                         = Paste and go
ПК>x ctrl                               = Cut
ПК>z ctrl                               = Undo
ПК>y ctrl                               = Redo
ПК>z ctrl shift                         = Redo
ПК>y ctrl shift                         = Undo
ПК>a ctrl                               = Select all
ПК>u ctrl                               = Clear
ПК>Ins                                  = Toggle overstrike
ПК>Del                                  = Delete
ПК>Platform Windows-Unix-QNX, Backspace = Backspace | Back
ПК>Platform Mac, Backspace              = Backspace | Delete | Back
ПК>


Судя по всему это кастомный формат. И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'. А кодировка определяется по строке с комментарием? А как работает whitespacing? А если у меня значение начинается с пробела?

С уважением, Gleb.
PS: написал за пять секунд что смотрел на твое сообщение. Возможно, если подумать, то можно придумать еще кучу вопросов.
Re[15]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 07.09.05 16:19
Оценка:
А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.

С уважением, Gleb.
Re[15]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 07.09.05 16:57
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Судя по всему это кастомный формат. И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'. А кодировка определяется по строке с комментарием? А как работает whitespacing? А если у меня значение начинается с пробела?


Ну да, конечно. Люди 10-тилетиями пользуются такими конфигами, и тут приходите вы ... Скажите честно, вы руками писали xml конфиг?
Re[16]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 07.09.05 17:07
Оценка: +3
Здравствуйте, Quintanar, Вы писали:

Q>Ну да, конечно. Люди 10-тилетиями пользуются такими конфигами, и тут приходите вы ... Скажите честно, вы руками писали xml конфиг?

Собственно не только я. У меня и пользователи(IT отделы клиентов) редактируют xml налево и направо. И как-то на незнание не жаловались. И кстати, пользуюсь я такими конфигами еще с 2000 года. Так что за пять лет жалобы должны были бы появиться.

С уважением, Gleb.
Re[16]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 07.09.05 17:23
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Если правильно писать — не больше одного копирования. А если писать еще

C>правильнее, и использовать строчки (flex_string'например) со счетчиком
C>ссылок — вообще копирований не нужно будет.
При использовании строк со счетчиком ссылок, будет все-таки одно копирование. В CAtlString счетчик есть, а flex_string — он входит в состав boost? Вообще меня CString полностью устраивает: не надо писать идиотских .c_str() каждый раз, когда передаешь сишную строку в функцию.


C>Ну да, но вопрос "писать свою _библиотеку_, или взять готовую" вообще

C>почти всегда разрешается в пользу готовой либы.
Я бы сказал 50/50. Есть куча уважаемых коммерческих либ, внутри которых вообще лучше не смотреть, чтобы кошмары ночью не снились В таких случаях лучше понять общую идею и сделать все правильно, чем править чужие баги, которые будут возвращаться снова и снова с каждым новым апдейтом. Если есть подходящая либа в бусте, тогда согласен на 100%.


C>Чуть-чуть изменить грамматику, ну примерно так:

C>
C>rule<> header=....; //Правило для заголовка
C>rule<> csv_file=header << ...; //И так далее
C>


>> а потом записи читались наоборот снизу, т.е. 1 запись уже последняя

>> строчка в файле?

C>Использовать деку вместо вектора и пихать строчки не push_back'ом,

C>push_front'ом.

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



C>Зачем? Если потребуется что-то уж очень нестандартное — то просто

C>пишется custom action, который вставляется как обработчик определенной
C>строки. Более того, в Spirit'е есть еще другой монстр под названием
C>Phoenix. В нем можно писать вот так:
C>
C>    int init[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
C>    vector<int> c(init, init + 10);
C>    typedef vector<int>::iterator iterator;

C>    for_each(c.begin(), c.end(),
C>        locals<int, char const*>(0, "...That's all\n")
C>        [
C>            for_(loc1 = 0, loc1 < arg1, ++loc1)
C>            [
C>                cout << loc1 << ", "
C>            ],
C>            cout << loc2
C>        ]
C>    );
C>

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

Меня аж в дрожь бросило Экстремально, впечатляет. А как быть, когда не известно заранее, будет эта строка вообще и если будет то где?
Re[15]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 08.09.05 02:29
Оценка:
GlebZ,

> Судя по всему это кастомный формат.


Нет, это .ini-файл.

> И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'.


Не нужно. Таких символов нет ни в названиях кодов клавиш, ни в названиях команд.

> А кодировка определяется по строке с комментарием?


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

> А как работает whitespacing?


Так же, как во всех .ini-файлах.

> А если у меня значение начинается с пробела?


Оно не может.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[16]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 08.09.05 02:31
Оценка: -1
GlebZ,

> А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.


Зачем? Приложение умеет обрабатывать только те shortcuts, о которых ему известно. Соответственно, и описание их ему известно, или оно знает, откуда их взять. В данном файле задаются только конкретные вещи -- соответствие команды и клавиатурного сокращения.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[15]: XML vs рукописный формат для конфигов
От: ArhAngelVezel Россия  
Дата: 08.09.05 04:43
Оценка:
Здравствуйте, GlebZ, Вы писали:


GZ>указать перевод строки или символ '=' или символ '|'.


так же как ты в xml будешь париться с символами '>' '<' '"'
нет универсального языка, в котором не было бы таких приколов.
Лично я начал пользоваться xml только когда перелез на .net ... не потому что это круто, а потому что я могу из данного xml десерилизовать классы всего одной строкой кода... удобно ...
Re[15]: XML vs рукописный формат для конфигов
От: FDSC Россия consp11.github.io блог
Дата: 08.09.05 05:35
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Странно. Почему ты решил, что я не хочу изучать какой-то класс? Да может, я сам его и написал когда-то, или уже пользовался им в похожих задачах.


Мне просто показалась, что тебе лень. Видимо, я ошибся.
Re[16]: Программирование стало более высокоуровневым?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.09.05 08:14
Оценка: +1
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>так же как ты в xml будешь париться с символами '>' '<' '"'


Зачем с ними париться? Там есть стандартные entity для них.

AAV>Лично я начал пользоваться xml только когда перелез на .net ... не потому что это круто, а потому что я могу из данного xml десерилизовать классы всего одной строкой кода... удобно ...


Так в том то вся и фишка, что вокруг XML есть масса готовых технологий.
... << RSDN@Home 1.2.0 alpha rev. 610>>
AVK Blog
Re[16]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 08.09.05 16:08
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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

Это уже ограничение Радостно видеть что ограничение документировано(строкой комментария).

Непонятно тогда, они как бы расширили семантику языка. А что будет если ctrl и shift я реверсну. То есть напишу наоборот: shift ctrl. Или сделаю то же самое для Platform Windows-Unix-QNX, Backspace. Это ведь уже семантика реализованная теми ребятами которые писали Opery, а не Windows. Следовательно, если введены правила, с которыми могут быть введены ограничения, то документированы ли они?
В принципе, это можно считать уже не ini файлом, а кастомным форматом. И тут у xml два плюса:
1. XML уже изначально многоуровневое дерево. В данном случае можно сказать что с многоуровневостью выпендреж. Например, если ini файл пришел в таком виде:

[Application]
ContextMenu = Show context menu

Ты можешь понять из текста, что это такое?

2. Существуют попутные технологии, которые могут описать семантику.
Просто поставляя схему вместе с xml, мы предлагаем пользователю инструмент проверки корректности.

С уважением, Gleb.
Re[17]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>GlebZ,


>> А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.


ПК>Зачем? Приложение умеет обрабатывать только те shortcuts, о которых ему известно. Соответственно, и описание их ему известно, или оно знает, откуда их взять. В данном файле задаются только конкретные вещи -- соответствие команды и клавиатурного сокращения.


Описание только пример. А расирений может быть куча. Например, сюда же можно добавить описание контекстного меню (иерархического). Да и описание может задаваться пользователем.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, Quintanar, Вы писали:

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


GZ>>Судя по всему это кастомный формат. И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'. А кодировка определяется по строке с комментарием? А как работает whitespacing? А если у меня значение начинается с пробела?


Q>Ну да, конечно. Люди 10-тилетиями пользуются такими конфигами, и тут приходите вы ...


Люди еще тысячилетиями пользовались кмаенным топором. Так что это не аргумент.

Q> Скажите честно, вы руками писали xml конфиг?


Да, в VS2005. Как и любой другой понимающий ХМЛ редатор она позовляет очень просто редактировать ХМЛ и проверять его вреность. Плюс можно сгенерировать по ХМЛ-ю схему (одним нажатием кнопки). Вот, например, схема для этого конфига:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="Shortcuts">
        <xs:complexType>
            <xs:sequence>
                <xs:element maxOccurs="unbounded" name="Shortcut">
                    <xs:complexType>
                        <xs:attribute name="Key" type="xs:string" use="required" />
                        <xs:attribute name="Action" type="xs:string" use="required" />
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>


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

Собственно далее элементарно делается визуальные редакторы. И т.п., и т.д.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка: -1
Здравствуйте, Павел Кузнецов, Вы писали:

>> Препдложи, плиз более подходящий формат,


ПК>
ПК>Opera Preferences version 2.0
...
ПК>Platform Windows-Unix-QNX, h ctrl    = Hide Opera
ПК>c ctrl shift                         = Copy to note
ПК>v ctrl                               = Paste
ПК>


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

Ну, а продолжим тем, что читать его значительно сложнее. Еще догадаться нужно что справа, что слева. Ну, а "Platform Windows-Unix-QNX, " чистейший левак. В ХМЛ-е бы можно было просто ввести атрибут или тег перечисляющий поддерживаемые платформы.

>> и попробуй обосновать этот выбор.


ПК>Ничего, специфичного для XML в твоем конфиге не используется, XML является только замусоривающей "обвязкой" вокруг твоего собственного формата.


ХМЛ это унивирсальный формат. Ему "специфичность" просто не нужна. Им что хочешь описать можно. Тем он и замечателен.

ПК> В случае выше оставлен необходимый и намного более читабельный минимум в виде собственного формата, без дополнительного мусора из тегов.


Что же в нем читабельного? Ни фига не ясно что это и зачем. Ты бы хоть "ИМХО" добавил бы.

>> Потом опиши что нужно предпринять для реализации твоего решения.


ПК>Не больше, чем в случае использования XML.


Да, больше. Но дело даже не вэтом. Еще раз напомню, что речь шала о собственном да еще и предлагалось его с помощью Яка/Лекса парсить.
Инифайлы довольно убогий формат. Пока их хватает конечно можно пользоваться и ими, но дальше начинаются извращения. Писать собственный формат для подобных случаев, по-моему, не очень разумно. И ХМЛ тут подходит просто замечательно.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>На самом деле, имхо, здесь два языка: первый -- XML со своими заморочками, а второй -- возможность опеределять комбинацию клавиш в одном атрибуте Key, разделяя названия с помощью вертикальной черты.


Два. Только конечно второй язык не определяет шорткаыт (это слишком простая вещь). Воторой язык это семантика данного DSL описывающего конфигурацию клавиатуры. Описание шортката всего лишь его составная часть.

E> Причем никакой XML редактор не оградит незадачливого пользователя от возможности написать Key="Shift+Up" или Key="Shift,Up" или Key="Shift-Up".


E>Уж если использовать XML для описания всего языка, то нужно было бы что-то вроде:

E>
E><?xml version="1.0" encoding="utf-8" ?>
E><Shortcuts>
E><Shortcut Key="Up" Shift="on"                Action="CaretViewLineUpExtend" />
E><Shortcut Key="Down" Shift="on"              Action="CaretViewLineDownExtend" />
E><Shortcut Key="Back" Alt="on" Shift="on"     Action="Redo"/>
E></Shortcuts>
E>


Можно и так. Разница не велика. Мой вариант мне нравится больше.

E>Но так, имхо, уже гораздо менее читабельно.


Мне тоже так кажется.

Собственно если вернуться к исходному вопросу, то согласись читается мой формат довольно хорошо. Его поддержку мне сильно упростило то что я использовал парсеры и другие фичи ХМЛ-я. Плюс не потребовалось долго думать о синтаксисе, так как ХМЛ его почти полностью определяет.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Тебе описали уже более подходящий формат. Я имел дело с XML языками. Поверь мне, даже Oberon лучше XML языка.


Сдается мне, что ты сейчас необъективен.

И главное, что ПК предложил точно такой же стандартный формат. Ты же предложил разрабатывать собственный с помощью Яка. Так что это можно расценивать как отказ от твоих же слов.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

GZ>>указать перевод строки или символ '=' или символ '|'.


AAV>так же как ты в xml будешь париться с символами '>' '<' '"'


&lt; &gt; или CDATA и никаких проблем. А вот что делать если нужно список создать, или не дай бог иерархию? Вот, например, во что превращаются инифайлы когда в них запихивают более лсожные конструкции:
cm_VisFlatInterface=2905;Interface: Flat/normal mode

(это из TOTALCMD.INC).
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 08.09.05 16:22
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

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


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

GZ>Это уже ограничение Радостно видеть что ограничение документировано(строкой комментария).
GZ>Непонятно тогда, они как бы расширили семантику языка. А что будет если ctrl и shift я реверсну. То есть напишу наоборот: shift ctrl. Или сделаю то же самое для Platform Windows-Unix-QNX, Backspace. Это ведь уже семантика реализованная теми ребятами которые писали Opery, а не Windows. Следовательно, если введены правила, с которыми могут быть введены ограничения, то документированы ли они?
GZ>В принципе, это можно считать уже не ini файлом, а кастомным форматом. И тут у xml два плюса:
GZ>1. XML уже изначально многоуровневое дерево. В данном случае можно сказать что с многоуровневостью выпендреж. Например, если ini файл пришел в таком виде:
GZ>

GZ>[Application]
GZ>ContextMenu = Show context menu

GZ>Ты можешь понять из текста, что это такое?
GZ>2. Существуют попутные технологии, которые могут описать семантику.
GZ>Просто поставляя схему вместе с xml, мы предлагаем пользователю инструмент проверки корректности.

Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения? Предлагаете изучать схему? Есть такое слово man (или help) и там должно быть все описано. В том числе можно ли менять местами shift и ctrl. А инструментом проверки корректности служит парсер файла.
Re[18]: XML vs рукописный формат для конфигов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.09.05 16:29
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения?


Многие редакторы (в том числе и VS 7+) умеют на основании схемы делать подсказки или хотя бы на лету схему проверять, выдавая внятные сообщения об ошибках.
... << RSDN@Home 1.2.0 alpha rev. 610>>
AVK Blog
Re[18]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 08.09.05 16:32
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения? Предлагаете изучать схему? Есть такое слово man (или help) и там должно быть все описано. В том числе можно ли менять местами shift и ctrl. А инструментом проверки корректности служит парсер файла.

1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.
2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.
3. Ты можешь высылать xml файлы, а не компилированные файлы.
4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.

С уважением, Gleb.
Re[15]: XML vs рукописный формат для конфигов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.09.05 16:34
Оценка: 5 (1) +2
Здравствуйте, VladD2, Вы писали:

E>>Уж если использовать XML для описания всего языка, то нужно было бы что-то вроде:

E>>
E>><?xml version="1.0" encoding="utf-8" ?>
E>><Shortcuts>
E>><Shortcut Key="Up" Shift="on"                Action="CaretViewLineUpExtend" />
E>><Shortcut Key="Down" Shift="on"              Action="CaretViewLineDownExtend" />
E>><Shortcut Key="Back" Alt="on" Shift="on"     Action="Redo"/>
E>></Shortcuts>
E>>


VD>Можно и так. Разница не велика. Мой вариант мне нравится больше.


E>>Но так, имхо, уже гораздо менее читабельно.


VD>Мне тоже так кажется.


VD>Собственно если вернуться к исходному вопросу, то согласись читается мой формат довольно хорошо. Его поддержку мне сильно упростило то что я использовал парсеры и другие фичи ХМЛ-я. Плюс не потребовалось долго думать о синтаксисе, так как ХМЛ его почти полностью определяет.


Так вот, имхо, в твоем варианте:
— во первых, пользователю все равно мало знать XML и XSD твоего документа. Ему нужно знать еще и формат записи клавиш внутри атрибута Key;
— продвинутые редакторы XML не помогут пользователю написать правильно атрибут Key. Ошибки, даже синтаксические, будут выявляться только в run-time.

Вот и интересно, так ли нужен был здесь XML с его тяжеловесным синтаксисом? Можешь не отвечать, это скорее риторический вопрос.
Просто мне кажестся, что если что-то предназначено для редактирования вручную, то лучше иметь читабельный синтаксис, а не XML. Например, вполне можно писать большие тексты для LaTeX-а, используя только Notepad или vi. А вот аналогичные по объему DocBook-и -- уже вряд ли.
И наличие специализированных XML редакторов для правки конфигов -- это скорее спасательный круг, а не нормальное положение вещей (ИМХО).
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 08.09.05 16:36
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.


И что? Чего это доказывает?

GZ>2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.


Что это за изменения?

GZ>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.


В обычном конфиге, можно подумать, ставит.
Re[19]: XML vs рукописный формат для конфигов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.09.05 16:41
Оценка: +1 -1
Здравствуйте, GlebZ, Вы писали:

Q>>Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения? Предлагаете изучать схему? Есть такое слово man (или help) и там должно быть все описано. В том числе можно ли менять местами shift и ctrl. А инструментом проверки корректности служит парсер файла.

GZ>1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.

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

GZ>2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.


Это точно. Более того, теговые структуры гораздо проще расширять новыми параметрами, чем yacc-грамматику.

GZ>3. Ты можешь высылать xml файлы, а не компилированные файлы.

GZ>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.

Имхо, это возможно в любой теговой структуре.

Просто XML слишком тяжеловесен для конфигов. Какой-нибудь документ из текстового процессора в XML сохранить -- это ради бога.
А если это конфиг на 30-40 параметров, то может лучше что-нибудь полегче? Например, YAML. Или lisp-подобные конструкции. Или даже фрагменты на скриптовых языках (Python, Ruby, JavaScript).
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 08.09.05 16:54
Оценка:
Здравствуйте, Quintanar, Вы писали:

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


Q>И что? Чего это доказывает?

Простота сопровождения (хотя бы на windows системах в которых я работаю).

Q>Что это за изменения?

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

GZ>>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.


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

В вышеприведенном примере это непонятно.

С уважением, Gleb.
Re[20]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 08.09.05 17:08
Оценка: +1
Здравствуйте, eao197, Вы писали:

GZ>>1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.


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

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

GZ>>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.


E>Имхо, это возможно в любой теговой структуре.

Почему бы и нет.

E>Просто XML слишком тяжеловесен для конфигов. Какой-нибудь документ из текстового процессора в XML сохранить -- это ради бога.

E>А если это конфиг на 30-40 параметров, то может лучше что-нибудь полегче?
И что в этом тяжелого? Вот использовать как протокол пересылки, тяжело(хотя подобная структура должна очень хорошо сжиматься по LZ алгоритмам). Действительно оверхед нехилый и тормозной. А вот для конфигов, очень даже круто и гибко получается.
E>Например, YAML. Или lisp-подобные конструкции. Или даже фрагменты на скриптовых языках (Python, Ruby, JavaScript).
Админов учить языку? Можно конечно сделать xslt с вставками JavaScript, но зачем? XML хорош тем, что его можно изучать вечно. Слишком много сопутсвующих технологий. С другой стороны, пользователю можно и не знать полностью спецификацию языка. Где и как вносить изменения интуитивно понятно. Да и распространение его уже таково, что сложно найти админа который бы не редактировал xml. А сопутствующие технологии им знать-то не обязательно.

С уважением, Gleb.
Re[21]: XML vs рукописный формат для конфигов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.09.05 19:03
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

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

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

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

E>>Просто XML слишком тяжеловесен для конфигов. Какой-нибудь документ из текстового процессора в XML сохранить -- это ради бога.

E>>А если это конфиг на 30-40 параметров, то может лучше что-нибудь полегче?
GZ>И что в этом тяжелого? Вот использовать как протокол пересылки, тяжело(хотя подобная структура должна очень хорошо сжиматься по LZ алгоритмам). Действительно оверхед нехилый и тормозной. А вот для конфигов, очень даже круто и гибко получается.

Как раз тащить для парсинга конфига XML-библитеку вроде Xerces или libxml2 -- это действительно круто
Другое дело языки вроде Java/C# или даже скриптовые -- там поддержка XML уже чуть ли не встроенная.
Только, имхо, забота там идет не о пользователе конфига, а о программисте, которому проще готовую структуру на XML замапить.

E>>Например, YAML. Или lisp-подобные конструкции. Или даже фрагменты на скриптовых языках (Python, Ruby, JavaScript).

GZ>Админов учить языку?

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

GZ> Можно конечно сделать xslt с вставками JavaScript, но зачем?


Вот это, действительно, зачем?

GZ> XML хорош тем, что его можно изучать вечно. Слишком много сопутсвующих технологий. С другой стороны, пользователю можно и не знать полностью спецификацию языка. Где и как вносить изменения интуитивно понятно. Да и распространение его уже таково, что сложно найти админа который бы не редактировал xml. А сопутствующие технологии им знать-то не обязательно.


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

А то, что многим админам приходится xml-ные конфиги править -- это еще не означает, что им нравится это делать
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 19:29
Оценка:
Здравствуйте, eao197, Вы писали:

E>Так вот, имхо, в твоем варианте:

E>- во первых, пользователю все равно мало знать XML и XSD твоего документа. Ему нужно знать еще и формат записи клавиш внутри атрибута Key;

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

E>- продвинутые редакторы XML не помогут пользователю написать правильно атрибут Key. Ошибки, даже синтаксические, будут выявляться только в run-time.


Ничего страшного. Зато в рантайме им будет выдано понятное сообщение об ошибке и они смогут исправить ее. К тому же это не защитит и в других случаях. И уж точно никакие Яки тут не помогут.

E>Вот и интересно, так ли нужен был здесь XML с его тяжеловесным синтаксисом?


А что в нем тяжеловесного то?

E> Можешь не отвечать, это скорее риторический вопрос.


Это вопрос пристрастий/привычек. Просто пока-что у многих людей, особенно тех что по старше. Есть откровенное недоверие к новому в том числе и к ХМЛ.

E>Просто мне кажестся, что если что-то предназначено для редактирования вручную, то лучше иметь читабельный синтаксис, а не XML.


Еще раз задам тот же вопрос. Ты что-то не понял в формате? Тогда зачем говорить не правду о четаемости. К тому же этот файл не файл данных которые нужно редактировать вручную. Это редко изменяемые настройки. К тому же никто не говорит, что их будут всю жизнь править вручную. Дойдет дело скорее всего сделаю редактор. Благо на ХМЛ-е это будет сделать очень просто. Читаем в DataSet... засовываем в DataView/DataGrid... прикручиваем комбики со списком команд... ну, может еще делаем считывание шортктов. Учитывая, что делается все не на плюсах работы, думаю, будет на пол дня (с отладкой).

E> Например, вполне можно писать большие тексты для LaTeX-а, используя только Notepad или vi. А вот аналогичные по объему DocBook-и -- уже вряд ли.


А причем тут это?

E>И наличие специализированных XML редакторов для правки конфигов -- это скорее спасательный круг, а не нормальное положение вещей (ИМХО).


Ты явно выдумывашь проблему там где ее нет.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 08.09.05 20:43
Оценка:
VladD2,

>>> А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.


> ПК>Зачем? Приложение умеет обрабатывать только те shortcuts, о которых ему известно. Соответственно, и описание их ему известно, или оно знает, откуда их взять. В данном файле задаются только конкретные вещи -- соответствие команды и клавиатурного сокращения.

>
> Описание только пример. А расирений может быть куча. Например, сюда же можно добавить описание контекстного меню (иерархического).

Нет проблем:

Opera Preferences version 2.0
; Menu specification file for Opera 7.0
; This file is stored in UTF-8 encoding

[Version]
File Version=2

[Info]
Name=Opera Standard
Description=Opera Standard menu setup
Author=Opera Software ASA
Version=1

[Links Panel Item Menu]

Item, 21204        = Open link
Item, 53018        = Open link in new page
Item, 53019        = Open link in background page
--------------------1
Item, 54020        = Open link in new window
Item, 67633        = Open link in background window
--------------------2
Item, 70463        = Add link to bookmarks
Item, 50216        = Copy
Item, 50761        = Download url as
Item, 67350        = Download url
--------------------4
Item, 67351        = Lock panel | Unlock panel

[Links Panel Download Menu]
Item, 50761        = Download url as
Item, 67350        = Download url


> Да и описание может задаваться пользователем.


"Все уже украдено до нас"

; Opera language file version 2.0
; Copyright й 1995-2005 Opera Software ASA. All rights reserved.
; Created on 2005-07-05 13:40
; Lines starting with ; (like this) are comments and need not be translated

[Info]
Language="en"
; The string below is the language name in its own language
LanguageName="English"
Charset="iso-8859-1"
Build.Win=7668
Version.Win=8.02
DB.version=519

[Translation]

; General strings

; Used in a popup error message when Opera can't connect to the remote
; server due to other phenomena than the one stated in 32873.
32869="Could not connect to remote server"

; The error code corresponding to this string is used in a number of
; situations when the server has abruptly closed the connection, and then
; the string can be used in a popup error message.
32864="Connection closed by remote server"

; Used in a popup error message when Opera has failed to load a requested
; page more than once.
32874="Repeated attempts failed to load this page completely.\r\n\r\nThere may be a problem on the server."

; Used in a popup error message when Operas request to connect to a server
; is refused. (For example when the server exists but does not answer on
; the specified port.)
32873="Could not connect to remote server"

Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[17]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 08.09.05 20:50
Оценка: +1
GlebZ,

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


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


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

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


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

> В принципе, это можно считать уже не ini файлом, а кастомным форматом. И тут у xml два плюса:

> 1. XML уже изначально многоуровневое дерево. В данном случае можно сказать что с многоуровневостью выпендреж. Например, если ini файл пришел в таком виде:
>

> [Application]
> ContextMenu = Show context menu

> Ты можешь понять из текста, что это такое?

А в фрагменте соответствующего XML?
<Area Name="Application">
   <Shortcut Key"ContextMenu" Command="Show context menu" />
</Area>

?

> 2. Существуют попутные технологии, которые могут описать семантику.

> Просто поставляя схему вместе с xml, мы предлагаем пользователю инструмент проверки корректности.

В т.ч. и "Key|ctrl|shift" vs. "Key|shift|ctrl"? Все равно, какая бы ни была схема, окончательной проверкой служит парсер, поставляемый в составе приложения, для которого этот конфиг написан.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re: XML vs рукописный формат для конфигов
От: all-x Россия http://treedl.sf.net
Дата: 08.09.05 21:05
Оценка: 18 (1)
Вот, кстати, вам статья по теме от создателя ANTLR:

Terence Parr
Soapbox: Humans should not have to grok XML
Answers to the question "When shouldn't you use XML?"

http://www-128.ibm.com/developerworks/xml/library/x-sbxml.html
Re[19]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 21:49
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Нет проблем:...


Надо очень нелюбить людей чтобы говорить, что тут нет проблем. Это же шифровка натуральная.
К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 09.09.05 04:58
Оценка:
VladD2,

> ПК>Нет проблем:...


> Надо очень нелюбить людей чтобы говорить, что тут нет проблем. Это же шифровка натуральная.


Ну, как ты понял, у нас по этому поводу мнения расходятся.

> К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?


А зачем здесь вложенные теги, чтобы визуального мусора больше было? Сама по себе информация в данном случае никакой особой вложенностью и иерархичностью не обладает...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 09.09.05 05:06
Оценка: +1
all-x,

> Вот, кстати, вам статья по теме от создателя ANTLR:

>
> Terence Parr
> Soapbox: Humans should not have to grok XML
> Answers to the question "When shouldn't you use XML?"
>
> http://www-128.ibm.com/developerworks/xml/library/x-sbxml.html

Terence Parr, co-founder of jGuru, demonstrates that XML makes a lousy human interface. He also provides questions to ask yourself to determine if XML is appropriate even for your project's program-to-program interface needs.


+1

С другой стороны, имхо, автор слишком уж поносит XML. У XML тоже есть преимущества в определенных сценариях. Например, если говорить о конфигах, для сложных иерархических конфигов, по которым желательно иметь возможность делать запросы вроде XPath. Вот здесь, да, сложность и неуклюжесть XML в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[4]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 09.09.05 07:10
Оценка:
Здравствуйте, eao197, Вы писали:


E>XML и его парсеры -- это конечно хорошо, только когда из автоматически распарсеного DOM-дерева нужно будет преобразовывать данные в какое-то внутренне представление, то вот здесь главные неприятности и проявляются.


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


E>Disclamer: речь шла о C++, для которого нет стандартных средств отображения структур данных на C++.



И что с того, что надо взять велосипедик? Можно взять аналог MS SAX и запихнуть все значения в структуры, не создавая предварительно дерева DOM, все будет быстро и красиво, ничуть не хуже custom- ini формата. А главное, избежишь заморочек с распарсиванием этого custom-формата.
У нас даже написали велосипед, который может писать/читать одновременно в реестр, ini и XML .Только это IMHO излишество. Я пользуюсь своим велосипедом на SAX для чтения настроек. Если приложение уже и так работает с XML (читает данные из него), IMHO не стоит разводить зоопарк из форматов. Самое главное в XML — то, что даже если возникнет такая необходимость править его ручками, справиться с этим сможет любой, хоть раз в жизни видевший теговую структуру файлов — не важно, xml это или html. Я когда-то ручками правил rtf — ничего, разобраться было не сложно — там тоже теги. Главное, что теговую структуру понимают все.
Re[21]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.09.05 11:35
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

>> К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?


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


Выделенное заметил?
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: XML vs рукописный формат для конфигов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.09.05 12:59
Оценка: +1
Здравствуйте, VladD2, Вы писали:

E>>Так вот, имхо, в твоем варианте:

E>>- во первых, пользователю все равно мало знать XML и XSD твоего документа. Ему нужно знать еще и формат записи клавиш внутри атрибута Key;

VD>Ты серьезно? Покажи мне хотя бы одного человека способного отредактировать конфиг и мало-мальски знающего английский и который не поймет семантику этого формата без объяснения.



Мы здесь балансируем на грани -- с одной стороны, в данном конкретном случае, действительно нет ничего сложного в выбранном формате конфига. С другой стороны, стоит только предположить что-то более сложное, например, возможное в будущем изменение формата конфига, как оказывается, что я черезмерно усложняю ситуацию. (Re[18]: Функциональные типы (параллельная ветка)
Автор: eao197
Дата: 28.06.05
, Re[19]: Функциональные типы (параллельная ветка)
Автор: VladD2
Дата: 29.06.05
-- в этом ответе есть замечательный вопрос "Зачем?", когда я предложил способ привязывать несколько hot-key к одному действию )

Кстати, а почему ты не использовал более простую запись вида "C-Home", "A-Backspace", "S-C-Left"?

E>>- продвинутые редакторы XML не помогут пользователю написать правильно атрибут Key. Ошибки, даже синтаксические, будут выявляться только в run-time.


VD>Ничего страшного. Зато в рантайме им будет выдано понятное сообщение об ошибке и они смогут исправить ее. К тому же это не защитит и в других случаях. И уж точно никакие Яки тут не помогут.


Страшного, конечно, ничего. Но и хорошего мало. Если у нас есть продвинутый XML редактор, который подсказывает, где нужно написать атрибут Key, а где элемент Shortcut, то жаль не использовать его возможности для того, чтобы подсказывать пользователю, как записывать модификаторы Shift, Alt и Control.

E>>Вот и интересно, так ли нужен был здесь XML с его тяжеловесным синтаксисом?


VD>А что в нем тяжеловесного то?


Закрывающие теги. Необходимость помнить про &gt;,&lt;,&amp;. Но главно -- это, конечно, закрывающие теги. Повбывавбы.

E>> Можешь не отвечать, это скорее риторический вопрос.


VD>Это вопрос пристрастий/привычек. Просто пока-что у многих людей, особенно тех что по старше. Есть откровенное недоверие к новому в том числе и к ХМЛ.


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

E>>Просто мне кажестся, что если что-то предназначено для редактирования вручную, то лучше иметь читабельный синтаксис, а не XML.


VD>Еще раз задам тот же вопрос. Ты что-то не понял в формате? Тогда зачем говорить не правду о четаемости. К тому же этот файл не файл данных которые нужно редактировать вручную. Это редко изменяемые настройки. К тому же никто не говорит, что их будут всю жизнь править вручную. Дойдет дело скорее всего сделаю редактор. Благо на ХМЛ-е это будет сделать очень просто. Читаем в DataSet... засовываем в DataView/DataGrid... прикручиваем комбики со списком команд... ну, может еще делаем считывание шортктов. Учитывая, что делается все не на плюсах работы, думаю, будет на пол дня (с отладкой).


Ну даже при твоих способностях бысто лабать на C# тебе все равно потребуется писать редактор. Который кто-то затем будет сопровождать. Хотя в текстовом редакторе этот же конфиг правится не сложнее. Да еще в возможностями поиска/замены и пр.

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

Вот например, как будет выглядеть следующий конфиг в XML?
{smpp_smsc
    {mbox    "aag_3::smpp_smsc::XXXXX.trx" }
    {smsc_map_mbox    "aag_3::smsc_map::default" }

    {ip "XXXXXXXXXX:15210" }

    {reconnect_timeout 30 }
    {restore_timeout 10 }

    {mode "transceiver" }

    {db    "smpp_smsc/XXXXXXXX"
        {template_cfg "aag_3/smpp_smsc/oess.db_template.cfg" } }

    {authentification

        {system_id    "XXXXXXXXXX" }
        {password    "XXXXXXXXX" }

        {interface_version 0x34 }

        {addr_ton    0x00}
        {addr_npi    0x01}

        {bind_resp_timeout    20 }
        {unbind_resp_timeout 20 }
    }

    {channel
        {enquire_link_timeout 30 }

        {sms_data_type::smpp2smsg
            {import_defaults "aag_3/sms_data_type/smpp2smsg.cfg"}

            {type "e_8bit_with_udh" {bit_string "00010101:*1******" }}
        }

        {sms_data_type::smsg2smpp
            {import_defaults "aag_3/sms_data_type/smsg2smpp.cfg"}

            {type    "e_8bit_sim_data_download"
                {esm_class    0x40 }
                {protocol_id    0x7f }
                {data_coding 0xf6 }
            }

            {type    "e_8bit_with_udh"
                {esm_class    0x40 }
                {protocol_id    0x7f }
                {data_coding 0xF6 }
            }

            {type    "e_16bit_with_udh"
                {esm_class    0x40 }
                {protocol_id    0x00 }
                {data_coding 0xF5 }
            }

            {type    "e_custom_03"
                {esm_class    0x00 }
                {protocol_id    0x00}
                {data_coding    0x19}
            }
        }

        {submit_sm
            {source_addr_ton 0x00 }
            {source_addr_npi 0x01 }
            {source_addr "XXXXXX" }
            {dest_addr_ton 0x01 }
            {dest_addr_npi 0x01 }
        }
    }

    {send_result_resend
        {resend_period    5}
        {group_size    10}
    }

    {receive_resend
        {resend_period    5}
        {group_size    10}
    }
}


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

E>> Например, вполне можно писать большие тексты для LaTeX-а, используя только Notepad или vi. А вот аналогичные по объему DocBook-и -- уже вряд ли.


VD>А причем тут это?


Ну при том, что ориентированный на человека формат, он и есть ориентированный на человека формат.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: XML vs рукописный формат для конфигов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.09.05 12:59
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>И что? Чего это доказывает?


GZ>>2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.


Q>Что это за изменения?


Re[12]: Формат конфигов
Автор: eao197
Дата: 22.06.05
-- вот здесь я пытался привести пример, в котором при расширении структуры конфига теговая организация оказывается удобнее в сопровождении, чем yacc-парсер. Не много притянуто за уши, но я столкнулся с подобными проблемами, когда реализовал себе Data Definition Language (DDL) на yacc-е, а при возникновении необходимости усложнить DDL начал бодаться с переписыванием парсера и изменением грамматики.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 09.09.05 15:34
Оценка:
VladD2,

>>> К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?


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


> Выделенное заметил?


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

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

    В любом случае, вопрос остается: зачем в данном случае вложенные теги, если описываемая информация не иерархична?
    Posted via RSDN NNTP Server 2.0 beta
  • Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[22]: XML vs рукописный формат для конфигов
    От: GlebZ Россия  
    Дата: 09.09.05 15:53
    Оценка:
    Здравствуйте, eao197, Вы писали:

    E>Интересно, а как XML может уменьшить форсмажорные ситуации?

    E>Как правило, конфиги приходится править на лету, чтобы последствия этого форсмажора преодолеть, когда у службы техподдержки уже собственных возможностей не хватает.
    Подавляющее количество проблем — это ошибки первой версии. Ну с этим понятно, это решается другими способами. И когда один "умный" человек, решил сделать "умную" настройку. Во втором случае, такую умную настройку сделать значительно сложней.

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

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

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

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

    GZ>> Можно конечно сделать xslt с вставками JavaScript, но зачем?

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

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

    Многим нравится. Я свидетель.

    С уважением, Gleb.
    Re[18]: XML vs рукописный формат для конфигов
    От: GlebZ Россия  
    Дата: 09.09.05 16:03
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

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


    ПК>В 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.
    Re[23]: XML vs рукописный формат для конфигов
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 09.09.05 16:30
    Оценка:
    Здравствуйте, 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-ек, как в конструкторе и кубиков (немного я говорил об этом здесь
    Автор: eao197
    Дата: 28.06.05
    ). Вот, к примеру, фрагмент конфига, который управляет настройкой приложения:
    {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>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[23]: XML vs рукописный формат для конфигов
    От: Quintanar Россия  
    Дата: 09.09.05 17:11
    Оценка: -1
    Здравствуйте, GlebZ, Вы писали:


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

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

    Не надо уж админов за дебилов держать. Хотя, конечно, я забыл. Вы ведь под Windows только работали. Там, может быть, от админов таких фундаментальных знаний и не требуют — главное уметь мышкой по табам кликать и xml в редакторе уметь писать.
    Re[24]: XML vs рукописный формат для конфигов
    От: GlebZ Россия  
    Дата: 09.09.05 17:21
    Оценка:
    Здравствуйте, 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.
    Re[24]: XML vs рукописный формат для конфигов
    От: GlebZ Россия  
    Дата: 09.09.05 17:34
    Оценка: 23 (1)
    Здравствуйте, Quintanar, Вы писали:

    Q>Не надо уж админов за дебилов держать.

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

    С уважением, Gleb.
    Re[25]: XML vs рукописный формат для конфигов
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 09.09.05 19:30
    Оценка:
    Здравствуйте, 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>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[23]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.09.05 22:00
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

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


    В данном случае вложенность одиночная, а информации в тегах ровно столько чтобы было без дополнительных объяснений ясно о чем идет речь. А вот в более сложном случае (о чем я гворил в выделенном тексте) у инифайлов бвли бы серьезные проблемы. Пришлось бы впихивать невпихуемое.
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.09.05 22:32
    Оценка:
    Здравствуйте, Quintanar, Вы писали:

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


    Интересно, что все разговоры о самопальных конфигах и применении разных Яков для их создания рано или поздно сваливаются в обсуждения XML vs. INI. А гед же Яки?
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.09.05 22:32
    Оценка:
    Здравствуйте, eao197, Вы писали:

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


    Терминалка работает через диалап на ура. Не "Формула 1" конечно, но вполне приемлемо.
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.09.05 22:32
    Оценка:
    Здравствуйте, eao197, Вы писали:

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


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

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


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

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


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

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


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

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


    Дык ты спроси их что им проще править конфиги на Курле или на ХМЛ-е. А то им вообще работать может не нравится.
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.09.05 22:32
    Оценка: :)
    Здравствуйте, Quintanar, Вы писали:

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


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

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

    В общем, не нужно окружающих за дебилов считать. Хотя конечно я забыл. Если человек под Линукс посидел, то это становится в норме вещей.
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.09.05 22:32
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    >> ПК>Нет, она всегда 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>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 09.09.05 22:35
    Оценка: +2
    Здравствуйте, 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 — это форменное издевательство над мозгом. И придумал этот синтаксис какой-то пакостник.

    В остальном — деревянная структура конечно же правильней. Хотя бы потому, что плоская структура является частным случаем иерархической.
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[25]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.09.05 22:51
    Оценка:
    Здравствуйте, 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>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 10.09.05 00:00
    Оценка: +2 :)
    Здравствуйте, 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>Между почим я не редко встречал очень похожую кострукцию в С++-ном коде. В нем, после закрывающей скобки ставится комментарий говорящий, что эта скобка закрывает. Мне так писать влом, да и часто забывал бы менять коментарии после изменения кода, но читать такой код очень даже удобно.


    Во-во. А почему тебе влом это писать? Не задумывался?
    И, честно сказать, я воспринимаю подобные "после-скобковые" комментарии как визуальный мусор. И пользы в них не вижу ни малейшей. Но это чисто моя имха.
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[25]: XML vs рукописный формат для конфигов
    От: Павел Кузнецов  
    Дата: 10.09.05 03:30
    Оценка:
    VladD2,

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


    У тебя неправильный Ниссан. В правильных тоже нужно жать сцепление и переключать скорости.
    Posted via RSDN NNTP Server 2.0 beta
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[23]: XML vs рукописный формат для конфигов
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 10.09.05 07:01
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


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


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


    Так я же и сказал (см.выделенное).
    ... << RSDN@Home 1.1.4 stable rev. 510>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[26]: XML vs рукописный формат для конфигов
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 10.09.05 07:55
    Оценка: 23 (2) +1
    Здравствуйте, 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>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[26]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.09.05 10:17
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

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


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


    Вы хотите об этом поговорить?
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: XML vs рукописный формат для конфигов
    От: Павел Кузнецов  
    Дата: 10.09.05 12:01
    Оценка: +1
    VladD2,

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


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


    > Вы хотите об этом поговорить?


    Вряд ли... О чем тут говорить, когда в дело пошла аргументация такого уровня/вида?
    Posted via RSDN NNTP Server 2.0 beta
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[25]: XML vs рукописный формат для конфигов
    От: Павел Кузнецов  
    Дата: 10.09.05 12:19
    Оценка:
    GlebZ,

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


    > <...> Есть админы операционных систем, баз данных. А есть админы крупных enterprize систем. И они вообще не обязаны знать какой-либо язык. Они должны быть проффесионалы в той предметной области, которую они администрят. И я, в 90 процентах случаев, я общаюсь именно с этими людьми. Это в большинстве случаев высокопроффесиональные специалисты.


    Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...
    Posted via RSDN NNTP Server 2.0 beta
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[25]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 10.09.05 15:05
    Оценка: 1 (1)
    McSeem2 wrote:

    > VD>В данном случае вложенность одиночная, а информации в тегах ровно

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

    Нет, для того, чтобы можно было XML валидировать в процессе чтения (то
    есть потоково). С неименоваными закрывающими скобками такого не получится.

    То есть:
    <a>
       asdfasdf
       <b>
           sadfjkasdhfkjsd
    </a>
    ...еще 100 килобайт текста....

    Ошибка будет обнаружена сразу при обнаружении несовпавших тэгов.

    А вот для неименованых скобок:
    {a
        asdfjkh
        {b
           sagafdshjgasdkfj
    }
    ...

    придется прочитать весь файл.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
    Re[26]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 10.09.05 15:55
    Оценка: 4 (1) -1
    Здравствуйте, Cyberax, Вы писали:

    C>Нет, для того, чтобы можно было XML валидировать в процессе чтения (то

    C>есть потоково). С неименоваными закрывающими скобками такого не получится.

    Есть в этом некий поинт. Но он настолько мизерный, что заставлять повторять имена — это просто издевательство. XML по определению должен быть well formed. Так же, XML не предполагает высокой эффективности при разборе (парсить надо). Следовательно, на каком этапе будет обнаружена ошибка — совершенно несущественно. Это гораздо более существенно для языков программирования, чтобы ткнуть пальцем в ошибку. Но что-то я не видел ни одного языка, который бы требовал закрывать блок с указанием имени. Почему? Да потому что не стоит оно того.

    На самом деле, причина в другом. Имена для закрывающих тагов важны для HTML. Идея в том, чтобы не иметь никакой диагностики вообще. Хоть черта лысого наколбась — хоть что-нибудь, да нарисуется. Там можно вообще повыкидывать половину закрывающих тагов без особого ущерба. Но иногда мы все-таки хотим закрывать некоторые элементы явным образом, и вот для этого как раз и требуется имя. Оно там жизненно необходимо просто в силу основной идеи, что любая абракадабра является валидной.

    XML отменил основную "прелесть" (в кавычках, конечно же) HTML. В XML все должно быть четко. Но при этом, груз дурной наследственности и "испорченной кармы" сделал свое грязное дело — отменить отменили, а лишний мусор выкинуть забыли .
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[26]: XML vs рукописный формат для конфигов
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 10.09.05 18:13
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Нет, для того, чтобы можно было XML валидировать в процессе чтения (то

    C>есть потоково). С неименоваными закрывающими скобками такого не получится.

    C>То есть:

    C>
    C><a>
    C>   asdfasdf
    C>   <b>
    C>       sadfjkasdhfkjsd
    C></a>
    C>...еще 100 килобайт текста....
    C>

    C>Ошибка будет обнаружена сразу при обнаружении несовпавших тэгов.

    C>А вот для неименованых скобок:

    C>
    C>{a
    C>    asdfjkh
    C>    {b
    C>       sagafdshjgasdkfj
    C>}
    C>...
    C>

    C>придется прочитать весь файл.

    +1

    Но на это есть симметричная ситуация:
    ...100 килобайт текста...
    <a>
        asddndnd
        <b>
            ssbddbdd
        </a> <!-- опс! а хотели </b> -->
    </a>
    ...


    И тот же случай для неименованных скобок:
    ...100 килобайт текста...
    {a
        asddndnd
        {b
            ssbddbdd
        }
    }
    ...


    К слову, в TeX уже больше двадцати лет применяются неименованные закрывающие скобки -- и все тип-топ.
    ... << RSDN@Home 1.1.4 stable rev. 510>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[26]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.09.05 21:33
    Оценка: -1
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...


    Паш, проффесионал это всего лишь человек который зарабатывает на жизнь некоторой проффесией. Так что раз их держат, то они автоматом проффесионалы.
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[28]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.09.05 21:33
    Оценка: -1
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Вряд ли... О чем тут говорить, когда в дело пошла аргументация такого уровня/вида?


    "Аргументация" такого уровня пошала у Quintanar-а. Я просто привел аналогию из другой области.
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: XML vs рукописный формат для конфигов
    От: Павел Кузнецов  
    Дата: 10.09.05 22:15
    Оценка: +1
    VladD2,

    > ПК> Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...


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


    Это одно из значений:

    профессионал
    1. Тот, кто сделал какое-л. занятие своей профессией (противоп.: любитель).
    2. Хороший специалист, знаток своего дела.

    В случае употребления сравнительных степеней ("высокопрофессиональный"), очевидно, речь идет о втором значении. В этом случае самого факта оплаты услуг данного человека (или того, что он зарабатывает этим на жизнь) не достаточно.
    Posted via RSDN NNTP Server 2.0 beta
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[27]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 11.09.05 05:12
    Оценка: :))
    Здравствуйте, VladD2, Вы писали:

    VD>Паш, проффесионал это всего лишь человек который зарабатывает на жизнь некоторой проффесией. Так что раз их держат, то они автоматом проффесионалы.


    В принципе, ты прав. Вон, узбеки-строители в Москве — тоже вроде-бы как-бы "профессионалы".

    (ничего не имею против узбекской нации!)
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[27]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 11.09.05 07:54
    Оценка: +1
    Здравствуйте, McSeem2, Вы писали:

    C>>Нет, для того, чтобы можно было XML валидировать в процессе чтения (то

    C>>есть потоково). С неименоваными закрывающими скобками такого не получится.
    MS>Есть в этом некий поинт. Но он настолько мизерный, что заставлять повторять имена — это просто издевательство.
    Это был один из design rationale.

    MS>XML по определению должен быть well formed.

    Ну да, а программы по определению должны быть без ошибок.

    MS>Так же, XML не предполагает высокой эффективности при разборе (парсить надо). Следовательно, на каком этапе будет обнаружена ошибка — совершенно несущественно.

    Очень даже существенно, если размер XML составляет много мегабайт, получаемых из сети.

    MS>Это гораздо более существенно для языков программирования, чтобы ткнуть пальцем в ошибку. Но что-то я не видел ни одного языка, который бы требовал закрывать блок с указанием имени. Почему? Да потому что не стоит оно того.

    if..end if
    if..fi
    case..esac

    Угадайте языки.
    Sapienti sat!
    Re[28]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 11.09.05 14:07
    Оценка: :))
    Здравствуйте, Cyberax, Вы писали:

    C>Очень даже существенно, если размер XML составляет много мегабайт, получаемых из сети.


    Ну, во-первых, eao197 привел контр-пример. Во-вторых, ошибка может возникнуть в конце файла. В-третьих, закрывающее имя решает лишь очень мизерную проблему общей валидации. В-четвертых, во-всех реальных форматах, основанных на XML (например, SVG, XAML), разрешены ссылки вперед. Это значит, что проверить валидность можно только лишь прочитав все. Я уже
    объяснял
    Автор: McSeem2
    Дата: 10.09.05
    , для чего и где реально нужны эти имена. Все попытки объяснить их "полезность" в XML — это аутотренинг какой-то.

    C>if..fi
    C>case..esac


    О! Мысль! Внести на рассмотрение вопрос, чтобы имя закрывающего тага писать наоборот. Для симметрии...
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[29]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 11.09.05 14:18
    Оценка: :)
    McSeem2 wrote:

    > C>Очень даже существенно, если размер XML составляет много мегабайт,

    > получаемых из сети.
    > Ну, во-первых, eao197 привел контр-пример.

    Нет, такая ошибка будет обнаружена сразу же:
    <a>
        asddndnd
        <b>
            ssbddbdd
        </a> <!-- опс! а хотели </b> -->
    </a>

    Закрывающий тэг </a> не соответствует открытому тэгу <b>.

    > Во-вторых, ошибка может возникнуть в конце файла. В-третьих,

    > закрывающее имя решает лишь очень мизерную проблему общей валидации.

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

    В общем, вы можете быть несогласны с XML design rationale, но вот
    реализация этого rationale — вполне приличная.

    > В-четвертых, во-всех реальных форматах, основанных на XML (например,

    > SVG, XAML), разрешены ссылки вперед. Это значит, что проверить
    > валидность можно только лишь прочитав все.

    А это уже проблемы форматов.

    > О! Мысль! Внести на рассмотрение вопрос, чтобы имя закрывающего тага

    > писать наоборот. Для симметрии...



    (главное не будить Сергея Губанова, а то он нам начнет рассказывать про
    отсутствие begin..end в Обероне).

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
    Re[30]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 11.09.05 14:41
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>XML был задизайнен так, чтобы его можно было представить в виде цепочки

    C>событий (SAX-модель), и при этом чтобы парсер не обязан хранить
    C>состояние разбора (и не использовать динамическую память). Без
    C>именованых закрывающих тэгов это сделать нельзя.

    Формально — да. Без закрывающих имен надо иметь стэк глубиной в максимальный уровень вложенности. Каков он может быть, этот уровень в реальности? Для уровня в миллион нужен стэк в миллион условных единиц памяти. Но это-же какой-то "сферический конь в вакууме". То есть, заведомо невостребованная задача.

    C>В общем, вы можете быть несогласны с XML design rationale, но вот

    C>реализация этого rationale — вполне приличная.

    Я бы не сказал. Хорошая имплементация (xerces) — это 13 мег исходников! А у MS — наверняка и поболе раза в два. И вообще, критерий таков — если имплементация полнофункционального парсера требует более 40 часов работы (неделя) — то это совершенно негодный и непрактичный формат.
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[28]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.09.05 15:26
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Это одно из значений:

    ПК>

    ПК>профессионал
    ПК>1. Тот, кто сделал какое-л. занятие своей профессией (противоп.: любитель).
    ПК>2. Хороший специалист, знаток своего дела.

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

    Вот и сделай вывод по поводу "Вряд ли в этом случае я смогу причислить их к профессионалам...".
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: XML vs рукописный формат для конфигов
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.09.05 15:44
    Оценка:
    Здравствуйте, McSeem2, Вы писали:

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


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


    MS>Этот аргумент не выдерживает ни малейшей критики.


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

    MS> Если у нас все написано в одну длинную строку,


    Любой объемный код написанный в одну строчку становится плохочиатаемым.

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


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

    Кстати, надо признать, что хотя синтаксис этого ХМЛ-С ты придумл на ходу, но у меня не возникло никаких проблем в его понимании и я без проблем переведу его обратно в С. А вот в обратное верится с трудом. Так что несмотря на большую объемность (по сравнению с С) надо отдать должное большей понятности ХМЛ-описания. Видимо это вызвано тем, что в коде присуствует меньше принимаемых по-умолчанию вещей. Так что избыточность может оказаться очень полезной в некоторых случаях.
    ... << RSDN@Home 1.2.0 alpha rev. 611>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 11.09.05 16:52
    Оценка:
    McSeem2 wrote:

    > C>XML был задизайнен так, чтобы его можно было представить в виде цепочки

    > C>событий (SAX-модель), и при этом чтобы парсер не обязан хранить
    > C>состояние разбора (и не использовать динамическую память). Без
    > C>именованых закрывающих тэгов это сделать нельзя.
    > Формально — да. Без закрывающих имен надо иметь стэк глубиной в
    > максимальный уровень вложенности. Каков он может быть, этот уровень *в
    > реальности*?

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

    > Для уровня в миллион нужен стэк в миллион условных единиц памяти. Но

    > это-же какой-то "сферический конь в вакууме". То есть, заведомо
    > невостребованная задача.

    Очень даже востребованая для realtime-систем, например. Или для
    потоковой обработки.

    > C>В общем, вы можете быть несогласны с XML design rationale, но вот

    > C>реализация этого rationale — вполне приличная.
    > Я бы не сказал. Хорошая имплементация (xerces) — это 13 мег исходников!

    Хорошая имплементация — это libxml. Компилируется в 200Кб либу (если без
    вкомпиленых кодовых страниц), в которой есть SAX и DOM.

    > А у MS — наверняка и поболе раза в два. И вообще, критерий таков —

    > если имплементация полнофункционального парсера требует более 40 часов
    > работы (неделя) — то это совершенно негодный и непрактичный формат.

    А зачем его писать-то самому? Уже написаны парсеры даже на чистом
    ассемблере.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
    Re[32]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 11.09.05 21:15
    Оценка: 1 (1) +1 -1
    Здравствуйте, Cyberax, Вы писали:

    C>А зачем его писать-то самому? Уже написаны парсеры даже на чистом

    C>ассемблере.

    Во! Значит, XML — это не просто формат. Это — формат плюс парсеры к нему! А парсеры неких сторонних производителей — это лишняя зависимость, иногда очень нежелательная — как ярмо.
    Вот я изобрел свой формат для AGDoc
    Его базовый синтаксис очень прост (TeX-like):
    \element[optional attributes]{content and/or elements}

    Базовый парсер для него, с полной диагностикой и разрешением всех возможных конфликтных ситуаций (маскирование управляющих символов) писался два дня и занимает 20K исходников на C++. А в XML требуются месяцы для нормальной имплементации с нуля. Это не формат данных, а монстр какой-то! Я не призываю писать XML-парсер. Я лишь рассматриваю сложность написания парсера в качестве оценочного критерия для формата. В XML — это явный перебор.
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[33]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 12.09.05 07:11
    Оценка:
    McSeem2 wrote:

    > C>А зачем его писать-то самому? Уже написаны парсеры даже на чистом

    > C>ассемблере.
    > Во! Значит, XML — это не просто формат. Это — формат плюс парсеры к нему!

    Плюс стандартизованые интерфейсы парсеров.

    > Базовый парсер для него, с полной диагностикой и разрешением всех

    > возможных конфликтных ситуаций (маскирование управляющих символов)
    > писался два дня и занимает 20K исходников на C++.

    А кодировки где? А поддержка entity? А DOM-модель? А валидация семантики
    с помощью аналога XSD? А автокомплит для Студии?

    > А в XML требуются месяцы для нормальной имплементации с нуля. Это не

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

    Я лично писал SAX-парсер для Java — чуть меньше дня работы. При этом у
    меня еще и кодировки поддерживались. Не было поддержки entity, но оно
    делается еще за пол-дня. Так что ничего в XML такого сверхсложного нет.

    В парсерах большую часть занимает поддержка валидации по DTD/XSD,
    поддержка стандартной DOM-модели и т.п.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
    Re[25]: XML vs рукописный формат для конфигов
    От: Quintanar Россия  
    Дата: 12.09.05 09:27
    Оценка:
    Здравствуйте, GlebZ, Вы писали:


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


    Я рад, что вы крутитесь в таких высоких сферах. Я же, увы, не дорос еще до общения с проФФесионалами. Все как-то с любителями приходится работать, которые не брезгуют изучить язык другой.
    Re[26]: XML vs рукописный формат для конфигов
    От: GlebZ Россия  
    Дата: 12.09.05 10:20
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...

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

    С уважением, Gleb.
    Re[34]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 12.09.05 15:26
    Оценка: 13 (2) +1 :)
    Здравствуйте, Cyberax, Вы писали:

    C>А кодировки где? А поддержка entity? А DOM-модель? А валидация семантики

    C>с помощью аналога XSD? А автокомплит для Студии?

    Кодировок нет, поддержка entity (аналог) — есть, DOM-модель — read-only, валидации семантики нет и не требуется. А автокомплит нужен как раз для XML с его закрывающими именами.

    Да это все не о том, на самом деле. Еще раз повторю, мне не нравится XML тремя вещами:
    1. Необходимостью повторять имя там, где по сути оно не нужно. Ни одного обоснованного аргумента о том, зачем нужны эти имена, приведено не было.
    2. Слишком много синтаксического мусора. Какой цели, например, служит требование заключать в кавычки все значения аттрибутов? Да, конечно, viewBox="0 0 1200 400" надо заключать в кавычки. Но почему нельзя написать width=1198?! Это что, упрощает парсер? Нисколько не упрощает, возможно даже усложняет. А когда этих аттрибутов много, становится очень плохо. А 99% всех аттрибутов как раз не требуют кавычек. Я не нахожу ни одной обоснованной причины для этого требования — чисто блажь.
    3. Уродскими комментариями.

    C>В парсерах большую часть занимает поддержка валидации по DTD/XSD,

    C>поддержка стандартной DOM-модели и т.п.

    Стандартная DOM-модель — это вообще нечто. Десятикратный и более перерасход по памяти! Позор!

    Кроме того, возьмем тот же SVG/XAML:
      <path d="M 50 142 L 100 152 C 483 251 496 62 26 333z"
            fill="none" stroke="green" stroke-width="100"/>


    То есть, этот "d=" надо еще "до-парсить". Почему бы не сделать чисто по-XML-ному?

      <path fill="none" stroke="green" stroke-width="100">
        <move-to x="50" y="142"/>
        <line-to x="100" y="152"/>
        <curve-to cx1="483" cy1="251" cx2="496" cy2="62" x="26" y="333"/>
        <close/>
      </path>


    А потому, что это было бы вообще издевательство. Сколько здесь лишних кавычек? И объем сразу увеличивается более чем вдвое.

    И при всем при этом, необходимость в закрыващих именах "объясняется" требованием эффективности — чтобы можно было писать без-стэковые парсеры! Не смешите мои тапочки. В общем, я не знаю, какие они программисты, эти W3C-шники, но инженеры они совершенно никудышные. Надо же было осчастливить мир таким стандартом-уродцем...

    Придется тоже заняться аутотренингом по поводу XML...
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[32]: XML vs рукописный формат для конфигов
    От: Vadim S. Беларусь  
    Дата: 12.09.05 16:47
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >Встречал с глубиной в несколько сотен. Кстати, в стеке надо еще будет

    >хранить и имена тэгов — так что уже достаточно чувствительный объем
    >получается.

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

    >> Для уровня в миллион нужен стэк в миллион условных единиц памяти. Но

    >> это-же какой-то "сферический конь в вакууме". То есть, заведомо
    >> невостребованная задача.
    >Очень даже востребованая для realtime-систем, например. Или для
    >потоковой обработки.

    Да-да. И в случае с XML этот поток возрастает в десятки раз. Именно из-за кучи мусора в потоке!
    Для real-time систем XML вообще не годится. Из-за его тормознутости и объема лишней информации.
    Re[33]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 12.09.05 17:11
    Оценка:
    Здравствуйте, Vadim S., Вы писали:

    VS>Прошу прощения, но как по-вашему парсер (или обработчик) проверит правильность следования тегов (даже имея закрывающие именованные теги), если он не хранит стек тегов открытых?

    Да, это я глючу.

    VS>Иначе говоря, преимущество закрывающих именовааных тегов, о котором тут пишут, таковым не является.

    VS>Поскольку стек тегов нужен в обоих случаях.
    VS>А если положиться на "правильность" структуры и не хранить стек, то тогда зачем вообще эти имена закрывающим тегам?
    Обработчик может быть почти stateless, если полагается на правильность XML.

    >>Очень даже востребованая для realtime-систем, например. Или для

    >>потоковой обработки.
    VS>Да-да. И в случае с XML этот поток возрастает в десятки раз. Именно из-за кучи мусора в потоке!
    VS>Для real-time систем XML вообще не годится. Из-за его тормознутости и объема лишней информации.
    Объем лишней информации к realtime'ности никак не относится. Да и не такой уж и большой оверхед в XMLе, как его все считают.
    Sapienti sat!
    Re[35]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 12.09.05 17:17
    Оценка:
    McSeem2 wrote:

    > C>А кодировки где? А поддержка entity? А DOM-модель? А валидация

    > семантики
    > C>с помощью аналога XSD? А автокомплит для Студии?
    > Кодировок нет, поддержка entity (аналог) — есть, DOM-модель —
    > read-only, валидации семантики нет и не требуется.

    Ну вот, парсер XML такого уровня помещается в 20 килобайт кода на C++.

    > А автокомплит нужен как раз для XML с его закрывающими именами.


    Зря, _умный_ (то есть понимающий контекст) автокомплит по XSD — вообще
    очень удобная вещь.

    > Да это все не о том, на самом деле. Еще раз повторю, мне не нравится

    > XML тремя вещами:
    > 1. Необходимостью повторять имя там, где по сути оно не нужно. Ни
    > одного обоснованного аргумента о том, *зачем* нужны эти имена,
    > приведено не было.

    Есть, кстати, SML (если не ошибаюсь), изоморфный XMLю — там можно не
    писать закрывающий тэг. Для него есть обычный SAX-парсер, выход которого
    можно скормить DOMу.

    > 2. Слишком много синтаксического мусора. Какой цели, например, служит

    > требование заключать в кавычки все значения аттрибутов? Да, конечно,
    > *viewBox="0 0 1200 400"* надо заключать в кавычки. Но почему нельзя
    > написать *width=1198*?!

    Для единообразия.

    > Это что, упрощает парсер?


    Да.

    > Нисколько не упрощает, возможно даже усложняет. А когда этих

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

    Недостаток, но не смертельный.

    > 3. Уродскими комментариями.


    Вот это действительно есть.

    > C>В парсерах большую часть занимает поддержка валидации по DTD/XSD,

    > C>поддержка стандартной DOM-модели и т.п.
    > Стандартная DOM-модель — это вообще нечто. Десятикратный и более
    > перерасход по памяти! Позор!

    Зато работать удобно

    > То есть, этот "d=" надо еще "до-парсить". Почему бы не сделать чисто

    > по-XML-ному?
    >
    > <path fill="none" stroke="green" stroke-width="100">
    > <move-to x="50" y="142"/>
    > <line-to x="100" y="152"/>
    > <curve-to cx1="483" cy1="251" cx2="496" cy2="62" x="26" y="333"/>
    > <close/>
    > </path>
    >
    > А потому, что это было бы вообще издевательство.

    Ну да, было бы логичнее.

    > И при всем при этом, необходимость в закрыващих именах "объясняется"

    > требованием эффективности — чтобы можно было писать без-стэковые
    > парсеры! Не смешите мои тапочки. В общем, я не знаю, какие они
    > программисты, эти W3C-шники, но инженеры они совершенно никудышные.
    > Надо же было осчастливить мир таким стандартом-уродцем...

    Ну как всегда — вся критика XMLя свелась к закрывающим тэгам....

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
    Re[33]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 12.09.05 21:51
    Оценка:
    Здравствуйте, Vadim S., Вы писали:

    VS>Прошу прощения, но как по-вашему парсер (или обработчик) проверит правильность следования тегов (даже имея закрывающие именованные теги), если он не хранит стек тегов открытых?

    VS>Иначе говоря, преимущество закрывающих именовааных тегов, о котором тут пишут, таковым не является.
    VS>Поскольку стек тегов нужен в обоих случаях.
    VS>А если положиться на "правильность" структуры и не хранить стек, то тогда зачем вообще эти имена закрывающим тегам?

    Вообще-то, если полагаться на правильность потока, то стэк не нужен. Все SAX-парсеры так и работают — они не валидируют парность тагов. Валидация происходит позже — в потребителе событий (например, DOM). А для этого надо передавать имя в onEndElement(). Это имя нужно только для валидации и ничего более, поскольку DOM не хранит имена дважды (а если хранит, то это какая-то помойка а не DOM).
    Но ценность этой валидации близка к нулю, а неудобства создает очень большие.
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re[3]: XML vs рукописный формат для конфигов
    От: c-smile Канада http://terrainformatica.com
    Дата: 13.09.05 00:26
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>

    ПК>Terence Parr, co-founder of jGuru, demonstrates that XML makes a lousy human interface. He also provides questions to ask yourself to determine if XML is appropriate even for your project's program-to-program interface needs.


    ПК>+1


    ПК>С другой стороны, имхо, автор слишком уж поносит XML. У XML тоже есть преимущества в определенных сценариях. Например, если говорить о конфигах, для сложных иерархических конфигов, по которым желательно иметь возможность делать запросы вроде XPath. Вот здесь, да, сложность и неуклюжесть XML в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.


    Странно, ничего обижающего XML я там не нашел.

    Касательно XPath и config... Павел, если честно, тебе часто приходится xpath'ом по большому configу ходить? Если да то имхо это уже задача DB какой а не XML.

    XML как межсистемный lingua franca хорош но как справедливо замечает автор статьи не панацея.

    Пример кстати грандиозного такого config: registry в windows
    Я думаю понятно почему в XML это хранить нельзя. Хотя оно "дерявянное".

    Даже в случае если надо в текстовом формате эту явно "древесную" информацию получить то выводят так:
    [HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\PerlScript\1.0]
    "NoCaseCompare"=dword:00000001
    "EnabledZones"=dword:00000010
    "EnableEventLogMsgs"=dword:00000000


    Это ж можно застрелиться если бы это все было уложено в XML tree.

    А так действительно — я могу пройтись grep'ом для того чтобы найти то что нужно.
    Re[4]: XML vs рукописный формат для конфигов
    От: Павел Кузнецов  
    Дата: 13.09.05 01:03
    Оценка:
    c-smile,

    > ПК>С другой стороны, имхо, автор слишком уж поносит XML. У XML тоже есть преимущества в определенных сценариях. Например, если говорить о конфигах, для сложных иерархических конфигов, по которым желательно иметь возможность делать запросы вроде XPath. Вот здесь, да, сложность и неуклюжесть XML в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.


    > Странно, ничего обижающего XML я там не нашел.


    Ну, может, мне показалось

    > Касательно XPath и config... Павел, если честно, тебе часто приходится xpath'ом по большому configу ходить? Если да то имхо это уже задача DB какой а не XML.


    Особенно запомнилось использование в одном проекте. Там с помощью большого XML задавались параметры UI игрушки + строки перевода. Особенно удобным оказалось то, что эти вещи, фактически, были связанными: картинки и размеры элементов в UI игры могут зависеть от языка. Плюс была зависимость от разрешения. Соответственно, удобным оказалось иметь иерархический XML-конфиг, в котором атрибутами задавалась привязка описаний тех или иных элементов к языку и разрешению экрана. Затем с помощью XPath запроса производилась фильтрация этого конфига под текущий язык и разрешение. Часть элементов от языка (а иногда и от разрешения) не зависела, соответственно, в их элементах язык и разрешение не указывались, что также дало функциональность настроек по умолчанию, которые перекрывалась только для части языков/расширений.
    Posted via RSDN NNTP Server 2.0 beta
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[28]: XML vs рукописный формат для конфигов
    От: raskin Россия  
    Дата: 13.09.05 06:10
    Оценка:
    Cyberax wrote:
    > if..end if
    Раздельно? Если слитно — то скрипты моего любимого редактора.
    > if..fi
    > case..esac
    Мой любимый после Паскаль?

    PS. Мне нравится Linux — языки понятны?
    Posted via RSDN NNTP Server 2.0 beta
    Re[4]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 13.09.05 06:13
    Оценка:
    c-smile wrote:

    > Даже в случае если надо в текстовом формате эту явно "древесную"

    > информацию получить то выводят так:
    >
    >[HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\PerlScript\1.0]
    >"NoCaseCompare"=dword:00000001
    >"EnabledZones"=dword:00000010
    >"EnableEventLogMsgs"=dword:00000000
    >
    >
    Когда создавался registry не было еще никакого XMLя.

    > Это ж можно застрелиться если бы это все было уложено в XML tree.

    > А так действительно — я могу пройтись grep'ом для того чтобы найти то
    > что нужно.

    s\grep\xpath

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
    Re[4]: XML vs рукописный формат для конфигов
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 13.09.05 08:44
    Оценка:
    Здравствуйте, c-smile, Вы писали:

    CS>Пример кстати грандиозного такого config: registry в windows

    CS>Я думаю понятно почему в XML это хранить нельзя. Хотя оно "дерявянное".

    Можно, если осторожно. "Реестр" для .NET приложений хранится как раз в XML.
    ... << RSDN@Home 1.2.0 alpha rev. 617>>
    AVK Blog
    Re[5]: XML vs рукописный формат для конфигов
    От: Mystic Украина http://mystic2000.newmail.ru
    Дата: 13.09.05 09:02
    Оценка: 12 (1) +1
    Здравствуйте, ArtemGorikov, Вы писали:

    AG>Самое главное в XML — то, что даже если возникнет такая необходимость править его ручками, справиться с этим сможет любой, хоть раз в жизни видевший теговую структуру файлов — не важно, xml это или html.


    А я вот не справился... Есть такой плагин к Far-у --- Colorer. Так вот, конфиги там в XML. Ну и захотелось мне создать расцветку для web-Файлов, внести изменения в форматы *.y и *.l для порта связки LEX + YACC на Delphi (стандартная расцветка работает с С), ну и немного видоизвенить расцветку для TeX, потому как так использовался по умолчанию LaTeX, а в макросах Д. Кнута часто переопределяются управляющие последовательности LaTeX, что приводило к тому, что определение \def могло нарушить структуру. Мучился я с этим долго, но ни разу не сумел настроить этот конфиг таким образом, чтобы меня это удовлетворило. При этом основные сложности возникали, как мне кажется, именно из-за формата XML. Точечное изменение сделать да, легко. Поменять "0" на "1" легко, но в случае сложной переплетенной архитектуры я большую часть времени тратил на лазание по этому XML с целью понять его структуру, взаимосвязи...

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

    Обратный пример --- я никогда не читал спецификации DFM, но проблем ни с пониманием, ни с редактированием у меня не возникало. И эстетически приятно.
    Re[34]: XML vs рукописный формат для конфигов
    От: Vadim S. Беларусь  
    Дата: 13.09.05 09:09
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Объем лишней информации к realtime'ности никак не относится. Да и не такой уж и большой оверхед в XMLе, как его все считают.


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

    Более того, на малых потоках данных оверхед будет больше 100% (если конечно имена тегов вразумительные).
    На больших потоках это уже зависит от разветвленности. Чем больше ветвей, тем больше оверхед.
    Для линейных данных оверхеда практически не будет, но тут уж и XML просто незачем.
    Re[3]: XML vs рукописный формат для конфигов
    От: Mystic Украина http://mystic2000.newmail.ru
    Дата: 13.09.05 09:18
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>С другой стороны, имхо, автор слишком уж поносит XML. У XML тоже есть преимущества в определенных сценариях. Например, если говорить о конфигах, для сложных иерархических конфигов, по которым желательно иметь возможность делать запросы вроде XPath. Вот здесь, да, сложность и неуклюжесть XML в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.


    А мне кажется, ключевое слово "иерархических". Потому что, например, когда я смотрел конфиги плагина Colorer для Far и пятался что-то в них править, добавлять, то было не совсем приятно...
    Re[34]: XML vs рукописный формат для конфигов
    От: Vadim S. Беларусь  
    Дата: 13.09.05 09:21
    Оценка:
    Здравствуйте, McSeem2, Вы писали:

    MS>Вообще-то, если полагаться на правильность потока, то стэк не нужен.


    Я именно об этом и говорил.

    MS>Все SAX-парсеры так и работают — они не валидируют парность тагов. Валидация происходит позже — в потребителе событий (например, DOM). А для этого надо передавать имя в onEndElement().


    Как я и сказал выше, стек нужен в любом случае, будь то сам парсер, либо, в случае с SAX, — обработчик (по вашему, потребитель событий). Потому что проверить правильность имени в onEndElement() можно, если имя уже хранится (в стеке, например). А если стека нет, то и сравнивать не с чем. Значит и имя тут не надо.

    Вообще, в закрывающих тегах с именами я вижу смысл, только если можно закрыть сразу весь контейнер, не закрывая все вложенные. Но это рассамтривается чаще всего как ошибка.
    Re[6]: XML vs рукописный формат для конфигов
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 13.09.05 09:56
    Оценка:
    Здравствуйте, Mystic, Вы писали:

    M>При этом основные сложности возникали, как мне кажется, именно из-за формата XML.


    Нее, основные сложности там не из-за xml, а из-за регексов.
    ... << RSDN@Home 1.2.0 alpha rev. 617>>
    AVK Blog
    Re[35]: XML vs рукописный формат для конфигов
    От: GlebZ Россия  
    Дата: 13.09.05 09:57
    Оценка:
    Здравствуйте, McSeem2, Вы писали:

    MS>Да это все не о том, на самом деле. Еще раз повторю, мне не нравится XML тремя вещами:

    MS>1. Необходимостью повторять имя там, где по сути оно не нужно. Ни одного обоснованного аргумента о том, зачем нужны эти имена, приведено не было.
    Исторические ноги.

    1.1 Origin and Goals
    ...
    3.XML shall be compatible with SGML.

    MS>2. Слишком много синтаксического мусора. Какой цели, например, служит требование заключать в кавычки все значения аттрибутов? Да, конечно, viewBox="0 0 1200 400" надо заключать в кавычки. Но почему нельзя написать width=1198?! Это что, упрощает парсер? Нисколько не упрощает, возможно даже усложняет. А когда этих аттрибутов много, становится очень плохо. А 99% всех аттрибутов как раз не требуют кавычек. Я не нахожу ни одной обоснованной причины для этого требования — чисто блажь.
    Это, врядли. Попробуй напиши EBNF для такого аттрибута. Посмотрим.
    MS>3. Уродскими комментариями.
    Аналогично. Исторические ноги.

    MS>Стандартная DOM-модель — это вообще нечто. Десятикратный и более перерасход по памяти! Позор!

    Зависит от реализации. В спецификации DOM не написано как будут храниться данные внутри.

    MS>Кроме того, возьмем тот же SVG/XAML:

    MS>
    MS>  <path d="M 50 142 L 100 152 C 483 251 496 62 26 333z"
    MS>        fill="none" stroke="green" stroke-width="100"/>
    MS>


    MS>То есть, этот "d=" надо еще "до-парсить". Почему бы не сделать чисто по-XML-ному?


    MS>
    MS>  <path fill="none" stroke="green" stroke-width="100">
    MS>    <move-to x="50" y="142"/>
    MS>    <line-to x="100" y="152"/>
    MS>    <curve-to cx1="483" cy1="251" cx2="496" cy2="62" x="26" y="333"/>
    MS>    <close/>
    MS>  </path>
    MS>


    MS>А потому, что это было бы вообще издевательство. Сколько здесь лишних кавычек? И объем сразу увеличивается более чем вдвое.

    А также имена . Это лишние аттрибуты. Если аттрибут не используется отдельно, то какой в нем смысл.

    MS>И при всем при этом, необходимость в закрыващих именах "объясняется" требованием эффективности — чтобы можно было писать без-стэковые парсеры!

    Ссылку в студию. Чушь какая-то.
    MS>Не смешите мои тапочки. В общем, я не знаю, какие они программисты, эти W3C-шники, но инженеры они совершенно никудышные. Надо же было осчастливить мир таким стандартом-уродцем...
    В W3C все инженеры — представители фирм и общественности. А это значит, что компании(типа Microsoft, Netscape, и Sun) и общественность "совершенно никудышная".

    С уважением, Gleb.
    Re[7]: XML vs рукописный формат для конфигов
    От: Mystic Украина http://mystic2000.newmail.ru
    Дата: 13.09.05 10:01
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    M>>При этом основные сложности возникали, как мне кажется, именно из-за формата XML.


    AVK>Нее, основные сложности там не из-за xml, а из-за регексов.


    С регулярными выражениями сложностей у меня как раз нет. Там все тривиально Все места, где надо было вставить regexp, работали на ура А вот со структурой (как в *.l и *.y файлах вместо расцветки C кода вставить расцветку Delphi кода, ...) я так до конца и не разобрался...
    Re[4]: XML vs рукописный формат для конфигов
    От: WolfHound  
    Дата: 13.09.05 11:40
    Оценка:
    Здравствуйте, Mystic, Вы писали:

    M>А мне кажется, ключевое слово "иерархических". Потому что, например, когда я смотрел конфиги плагина Colorer для Far и пятался что-то в них править, добавлять, то было не совсем приятно...

    А может надо было мануал почитать?
    Личо у меня после прочтения мануала не возникло проблем с созданием своих схем.
    ... << RSDN@Home 1.1.4 beta 6a rev. 436>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[6]: XML vs рукописный формат для конфигов
    От: Quintanar Россия  
    Дата: 13.09.05 13:05
    Оценка: +1 :)
    Здравствуйте, Mystic, Вы писали:

    M>Вообле всякий раз, когда приходитсмя работать с XML, меня не покидает чувство дискомфорта, связаного именно с этим форматом. Отсутсвие эстетичности, лаконичности, удовольствия... За годя четыре я так и не смог привыкнуть к нему и принять его. Действует на подсознание, нервы и ничего не могу поделать...


    Точно. XML уродлив, с ним просто неприятно работать, куча времени тратится на "синтаксический оверхед" типа тех же закрывающихся тегов. А как в один голос твердят известные программерские авторитеты — уродливое не может быть хорошим.
    Re[5]: XML vs рукописный формат для конфигов
    От: Mystic Украина http://mystic2000.newmail.ru
    Дата: 13.09.05 15:53
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    WH>Личо у меня после прочтения мануала не возникло проблем с созданием своих схем.


    Читал. Это первое что я сделал, когда я увидел настроечные файлы. Думаю, мне просто не хватило терпения. Мне надо было не создать с нудя свою схему, а использовать существующие... И собственно говоря, лазить по XML смотреть как реализованы существующие форматы, думать где в них надо внести изменения отнюдь не было приятной прогулкой.
    Re[4]: XML vs рукописный формат для конфигов
    От: Lloyd Россия  
    Дата: 13.09.05 16:27
    Оценка:
    Здравствуйте, c-smile, Вы писали:

    CS>Пример кстати грандиозного такого config: registry в windows

    CS>Я думаю понятно почему в XML это хранить нельзя. Хотя оно "дерявянное".

    А вот в IIS с 6-й версии таки перешли на хранение метаданных в виде xml.
    ... << RSDN@Home 1.1.4 stable rev. 510>>
    Re[36]: XML vs рукописный формат для конфигов
    От: McSeem2 США http://www.antigrain.com
    Дата: 13.09.05 19:24
    Оценка: 3 (1)
    Здравствуйте, GlebZ, Вы писали:

    GZ>Исторические ноги.

    GZ>

    GZ>1.1 Origin and Goals
    GZ>...
    GZ>3.XML shall be compatible with SGML.


    Вот поэтому я и говорю — действовали по принципу "чего тут думать — трясти надо".

    "...А мы чо? Мы ниче! Другие вон чего — и то ничего!"

    SGML, на самом деле, гораздо более логичен.
    Это я к тому, что AFAIK элементы в SGML можно перескать в определенных случаях. Так же, допустимо опускать закрывающие таги в "плоских" случаях:
        <anthology>
             <poem><title>The SICK ROSE
             <stanza>
                  <line>O Rose thou art sick.
                  <line>The invisible worm,
                  <line>That flies in the night
                  <line>In the howling storm:
             <stanza>
                  <line>Has found out thy bed
                  <line>Of crimson joy:
                  <line>And his dark secret love
                  <line>Does thy life destroy.
             <poem>
                  <!-- more poems go here    -->
        </anthology>

    Это значит, что в SGML имена в закрывающих тагах жизненно необходимы, так же, как и в HTML (не XHTML!). В XML же это упразднили, но имена оставили. Никакого другого назначения, кроме как "чтоб было как у них", эти имена не имеют. Следовательно, они являются мусором.

    GZ>Это, врядли. Попробуй напиши EBNF для такого аттрибута. Посмотрим.


    Не хочу. Мне достаточно того, что подобное поведение реализовано во всех командных процессорах. Если имя файла содержит пробелы — заключи его в кавычки. И реализуется это настолько элементарно, что даже не стоит упоминания. Тем более, и в SGML и в XML так и есть — можно без кавычек. Получается, что если такую простую конструкцию нельзя записать в EBNF, то надо весь мир загнать пинками в рай — пусть пишут кавычки. "В EBNF это представить невозможно — вот и нечего тут трындеть. Умники нашлись. Кавычки им не нравятся..."

    MS>>Стандартная DOM-модель — это вообще нечто. Десятикратный и более перерасход по памяти! Позор!

    GZ>Зависит от реализации. В спецификации DOM не написано как будут храниться данные внутри.

    Практически не зависит. Я не видел ни одной реализации с менее чем 10-кратным перерасходом. На примере SVG я вижу, что эти "теоретики" никогда ничего не пытались делать сами. Они только теоретизируют. И их любимая отмазка — "спецификация не определяет, как это можно имплементировать". Это я не к тому, чтобы надо, чтоб она определяла, а к тому, что слишком частое употребление этой отмазки приводит к вещам нереализуемым на практике. А потом они удивляются — "а чо наш SVG так плохо продвигается?"

    MS>>И при всем при этом, необходимость в закрыващих именах "объясняется" требованием эффективности — чтобы можно было писать без-стэковые парсеры!

    GZ>Ссылку в студию. Чушь какая-то.

    Это Cyberax приводил такой аргумент, но потом он взял его назад

    GZ>В W3C все инженеры — представители фирм и общественности. А это значит, что компании(типа Microsoft, Netscape, и Sun) и общественность "совершенно никудышная".


    Урок логики (читать внимательно). Если в комитете работает некудышный представитель Microsoft, то из этого не следует, что все остальные люди в Microsoft тоже являются никудышными. Эти вещи не являются логически связанными. Do I make myself clear?
    McSeem
    Я жертва цепи несчастных случайностей. Как и все мы.
    Re: XML vs рукописный формат для конфигов
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 18.09.05 18:37
    Оценка:
    Здравствуйте, ArtemGorikov, Вы писали:

    AG>2) XML и куча парсеров к нему, на любой вкус.


    Вот в этой теме
    Автор: Зверёк Харьковский
    Дата: 17.09.05
    я упомянул
    Автор: eao197
    Дата: 18.09.05
    Ruby On Rails. Но, поскольку сам я эту штуку еще не использовал, решил просмотреть некоторые описания Ruby On Rails. И вот, на что наткнулся

    Из Rolling with Ruby on Rails:

    What would you think if I told you that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework? You can--without making any sacrifices in the quality of your application! How is this possible?

    Part of the answer is in the Ruby programming language. Many things that are very simple to do in Ruby are not even possible in most other languages. Rails takes full advantage of this. The rest of the answer is in two of Rail's guiding principles: less software and convention over configuration.

    Less software means you write fewer lines of code to implement your application. Keeping your code small means faster development and fewer bugs, which makes your code easier to understand, maintain, and enhance. Very shortly, you will see how Rails cuts your code burden.

    Convention over configuration means an end to verbose XML configuration files--there aren't any in Rails! Instead of configuration files, a Rails application uses a few simple programming conventions that allow it to figure out everything through reflection and discovery. Your application code and your running database already contain everything that Rails needs to know!


    Из книги Agile Web Development with Rails:

    Dave’s Top 10 Reasons To Like Rails
    1. It brings agility to web development.
    2. I can create web pages with neat effects, just like the cool kids do.
    3. It lets me focus on creating the application, not feeding the framework.
    4. My applications stay maintainable as they grow.
    5. I get to say “Yes” to clients more often.
    6. Testing is built-in (and easy), so it gets used.
    7. Instant feedback: edit the code, hit Refresh, and the change is in my browser.
    8. Metaprogramming means I can program at a really high level.
    9. Code generators let me get started quickly.
    10. No XML!


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


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[2]: XML vs рукописный формат для конфигов
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 19.09.05 05:47
    Оценка: :)
    Здравствуйте, eao197, Вы писали:
    E>Из книги Agile Web Development with Rails:
    E>

    E>Dave’s Top 10 Reasons To Like Rails
    E>10. No XML!


    Раз пошла такая пьянка, то можно обратиться к авторитетам. Вот что об єтом думает Jeffrey Richter:

    Because editing an XML configuration file is a little unwieldy, Microsoft’s .NET Framework
    team produced a GUI tool to help.

    Мыши плакали, кололись, но...
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[2]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 19.09.05 07:43
    Оценка:
    eao197 wrote:

    > AG>2) XML и куча парсеров к нему, на любой вкус.

    > Вот в этой теме <http://rsdn.ru/forum/Message.aspx?mid=1388141&amp;only=1&gt;
    Автор: Зверёк Харьковский
    Дата: 17.09.05

    > я упомянул <http://rsdn.ru/forum/Message.aspx?mid=1388606&amp;only=1&gt;
    Автор: eao197
    Дата: 18.09.05
    Ruby

    > On Rails <http://www.rubyonrails.org/&gt;. Но, поскольку сам я эту штуку
    > еще не использовал, решил просмотреть некоторые описания Ruby On
    > Rails. И вот, на что наткнулся

    К сожалению, был опыт использования ROR в _реальном_ проекте. В общем
    "at least ten times faster" — ТУФТА. Пока делается то, что
    предусматривалось авторами ROR, то все идет нормально. Но стоит сделать
    шаг влево/вправо — сразу начинаются проблемы.

    Например, object-relational mapping в ROR сделан просто топорно.
    Поддержка многостраничных форм была сделана криво, биндинг к полям форм
    был слегка неправильным и т.п.

    В итоге, переписали все на старом добром Hibernate+JSP+JSF

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
    Re[3]: XML vs рукописный формат для конфигов
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 19.09.05 08:36
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>К сожалению, был опыт использования ROR в _реальном_ проекте. В общем

    C>"at least ten times faster" — ТУФТА. Пока делается то, что
    C>предусматривалось авторами ROR, то все идет нормально. Но стоит сделать
    C>шаг влево/вправо — сразу начинаются проблемы.

    Имхо, это везде так, шаг влево, шаг вправо за пределы framework-а и ты один в чистом поле. Имхо, в JSP в свое время то же так было.

    C>Например, object-relational mapping в ROR сделан просто топорно.

    C>Поддержка многостраничных форм была сделана криво, биндинг к полям форм
    C>был слегка неправильным и т.п.

    А какую версию ROR использовали, если не секрет?

    И еще интересно, а из-за чего был взят ROR? У вас в конторе были Rubyist-ы?
    ... << RSDN@Home 1.1.4 stable rev. 510>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[4]: XML vs рукописный формат для конфигов
    От: Cyberax Марс  
    Дата: 19.09.05 08:59
    Оценка:
    eao197 wrote:

    > C>К сожалению, был опыт использования ROR в _реальном_ проекте. В общем

    > C>"at least ten times faster" — ТУФТА. Пока делается то, что
    > C>предусматривалось авторами ROR, то все идет нормально. Но стоит сделать
    > C>шаг влево/вправо — сразу начинаются проблемы.
    > Имхо, это везде так, шаг влево, шаг вправо за пределы framework-а и ты
    > один в чистом поле. Имхо, в JSP в свое время то же так было.

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

    Кстати, у меня коллега назвал ROR — "VB для Web'а".

    > C>Например, object-relational mapping в ROR сделан просто топорно.

    > C>Поддержка многостраничных форм была сделана криво, биндинг к полям форм
    > C>был слегка неправильным и т.п.
    > А какую версию ROR использовали, если не секрет?

    Не я проект делал, год назад примерно было. Приду на работу — спрошу.

    > И еще интересно, а из-за чего был взят ROR? У вас в конторе были

    > Rubyist-ы?

    Было интересно попробовать — специально взяли не очень важный проект с
    достаточно большим запасом по сроку. Рубисты у нас есть — бывшие
    Перловщики, хотя пишут сейчас большей частью на Java.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 2.0 beta
    Sapienti sat!
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.