yoctoXML - маленький и быстрый XML парсер

>Ключ значение поддерживающее сабститьюшены и мапы со значениями 
>xpath! Мутанты форэвер

Ты уверен, что это нужно хранить в конфиге? O_o
Речь, напомню, шла о формате для хранения конфигурационной информации.

у вас групповое заблуждение. для конфигов круче ini файлов еще не было придумано

>для конфигов круче ini файлов еще не было придумано

В большинстве случаев можно обойтись boost::program_options - умеет читать ini-подобные файлы.

> Так как создавался для узкой цели -- файлы конфигурации.

Для таких примитивных конфигов лучше что-то ini-подобное.

> XML - зло ! Но деваться некуда, это зло повсюду.

Винда - зло ! Но деваться некуда, это зло повсюду.


------8<------
panel1.label1=xml_is_bad
panel1.label2 = xml is slow
panel1.label3 = xml is a danger for your eyes

panel1.panel2.panel3=I can do hierachies without problems too. My file is smaller and it is more robust (even redundant)

panel1.label4 = conserve energy - do not overload processor by unnecessary xml!

panel1.code = I can do lists as well, what do you need? Variables? Programming language in config? Use DSL, custom parser, Luke (for the right side)
------8<------

Можно добавить большой недостаток ХМЛ - избыточность аттрибутов и элементов, чего нет в JSON, например (не говоря о ключ-значение, где значение - DSL.

Конфиг с хешем на C, где действительно (с одним действием в строке) - 200 строк, не считая шапок и комментариев:
http://sourceforge.net/projects/aisconfig/

Потом быстрота в чтении конфига не важна, а важна - быстрота доступа (т.е. и аттрибуты и элементы должны быть индексированы, когда их много, но с другой стороны если есть индексация - то зачем изначальный кривой ХМЛ-формат?) Сравните вытаскивание по ключам из хеша и вытаскивание по аттрибутам, элементам этого конфига.
сравнение с доступом к 30к элементам к хэшам - порядка 100мсек.:
http://siberean.livejournal.com/2253.html
а сколько у yХМЛя?

>Можно добавить большой недостаток ХМЛ - избыточность аттрибутов и элементов, чего нет в JSON, например

ORLY? Вы его руками то пробовали править? Геморрой куда хуже XML'а.

кто поддерживет ХМЛ в конфигах - ССЗБ. Потом жалуются - что он - всюду.
Это виндузятничество.
(И не всюду он! Он пришёл только что, с школотой, в 2000-е. Раньше его не было. И в нормальных местах - его ещё нет, и надеюсь - не будет).

Я уже всех студентов пересадил на проперти/ini - все довольны (открытие, блин!). Зачем вы его учили? (говорили же вам - в 90-е - не учите эту херню!)

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

А для ручной правки - только проперти/ini
(потому что человек читает слева направо, строками)

>кто поддерживет ХМЛ в конфигах - ССЗБ

ORLY? Для сложных, древовидных конфигов init даст немного выйгрыша, зато потерям удобства XML: проектирование структуры конфигов => автоматическая валидация и комплишн в редакторе конфига + автоматическая генерация кода.

Да-да можно пользоваться не редакторами типа nano, а чем-то более разумным позволяющими всё перечисленное.

Ну так вот, тут велосипед для конфигов :}

В смысле я намекаю, что конфиги часто правят руками.

Те, кто реально им пользуются не жалуются, жалуются несколько другие люди :}

какая валидация??? ("не читайте по утрам советски^Щ рекламмок"):
Что ХМЛ валидирует?
Если у вас индекс не совпадает со страной (элементарная валидация) - ХМЛ это сделает?
А если 99% валидации всё равно в коде - почему вы цепляетесь за несколько примитивных чеков, о которых и говорить смешно?
Запомните: вся ваша программа - это валидация.

или вот другая самая распространённая валидация - по регэкспам

> Да-да можно пользоваться не редакторами типа nano, а чем-то более разумным позволяющими всё перечисленное.


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

> Да-да можно пользоваться не редакторами типа nano, а чем-то более разумным позволяющими всё перечисленное.

а как насчёт редактирования через cat/echo/grep/sed/awk/cut/etc?

У тебя клавиши залипают.

> потому что человек читает слева направо, строками

Вот откуда такая ненависть к евреям и арабам?

>Что ХМЛ валидирует?

XML - ничего. Валидируют (и вообще позволяют всё что я описал) DTD (устарело, но кое-где применяется), XSD, Relax-NG, Schematron

>Запомните: вся ваша программа - это валидация.

Зпасибо дядя! Можно я как-нить без ваших советов? Я предпочитаю работать с заранее провалидированными данными, при чём текста валидации хочу писать минимум. То что я написал выше это позволяет.

И АФАИК японцам =)

>ну вот, сначала придумываем формат, который без редактора не отредактируешь, а потом - не можем простой конфиг зафиксить в vi. И подавай очередной IDE. Почему тогда оффтопиковскую студию не взять и не парится?

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

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

>или вот другая самая распространённая валидация - по регэкспам

RelaxNG, XSD - оба стандарты ISO, XSD - стандарт де-факто, прекрасно позволяет.

>запомните - что xml - это виндоуз-вей

Пророк-аналитик детектед.

Да вы всё страньше и страньше, толще и ТОЛЩЕ! Аргументация на уровне средненького тролля кричщего "ххх-ГОВНО" тролля.

> И АФАИК японцам =)

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

ОК, извиняюсь перед евреями/арабами (и справа налево тоже: там ведь - тоже строки).
Экран - двумерный, а человек - не стековая машина/парсер. Ему надо читать по кусочкам, коими явлются строки (будь то справа-налево или иероглифы).

Да вы, батенька, полиглот?

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

что не ясно? аргументации, приведённой выше - надеюсь кватит (и надолго).

давайте не скатываться сами знаете на что - когда по существу нет аргументов.
Прочитайте ваш ХМЛ со всем словарём английских слов за 100мс для начала и доступитесь 30000 раз до ключей - потом будем говорить.

>Ему надо читать по кусочкам, коими явлются строки

Аргументация? Простейший пример - конфиг хранит организацию менюх. Или списко химических веществ. ini файлы в обоих случаях плохо подходят.

>Прочитайте ваш ХМЛ со всем словарём английских слов за 100мс для начала и доступитесь 30000 раз до ключей - потом будем говорить.

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

>аргументации, приведённой выше - надеюсь кватит (и надолго).

Не увидел ни одного аргументированного перехода. Сплошной поток сознания.

>ini файлы в обоих случаях плохо подходят.

выше сказано - почему не плохо, а наоборот - хорошо.

уровень1.уровень2.1=меню1
уровень1.уровень2.2=меню2

или что угодно.

Потом есть 2 формата для правой части: фиксированной длинны или делимитед. Храните что угодно и как удобно, как я сказал вплоть до ДСЛ.

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

я в курсе - как обрабатываются межбанковские транзакции. Свифт которому наверное лет 20 - Никакого ХМЛя. Кастом протокол для мессаг (самое эффективное).
Везде где перешли на ХМЛ - тормоза.

> Не увидел ни одного аргументированного перехода. Сплошной поток сознания.

бай-бай тогда.

>бай-бай тогда.

бай-бай. скуууушно с вами.

ITT Самый унылый анти-XML троллинг за последний год…

Чем это правка jsonа так неудобна? Там сущностей то меньше,чем в XMLе как бы, где там запутаться можно ? а ежели редактор поддерживает автодополнение то править их ваще одно удовольствие

Запятые — излишние сущности (то, что они нужны парсеру не волнует никого, кроме самого парсера), кавычек там так же море, как и в XML. При повышении уровня вложенности JSON становится сложнее воспринимать адекватно очень быстро :\ И как следствие копипастить не так уж и удобно. Шило на мыло. Ничем особо не лучше XML'а.

Каждому инструменту свой круг задач, и не надо фанатизма. В конце универа и в аспирантуре я работал в лаборатории в которой для обработки экспериментальных данных использовался очень навороченный самописанный фреймворк, с конфигами в XML. К сожалению там всё было вынесено в XML конфиг. Для того, чтобы нормально запускать обработку пришлось писать пару баш скриптов активно использующих grep/sed для замены в таком конфиге тех параметров которые приходится менять часто.

Другой пример: Ant и вещи ему подобные. XML слишком избыточен, что очень затрудняет его чтение. Build Файлы легко генерятся идешкой, но потом разобраться в этом невозможно. А когда пишешь руками, то тупо материшься пытаясь сделать это удобочитаемым.

Я не противник XML но тупо пихать его везде не нужно.

В мире есть утилиты помимо grep и sed. Ищите и обрящете.

> В мире есть утилиты помимо grep и sed. Ищите и обрящете.

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

2 Mystra_x64


> Запятые — излишние сущности

ложь

запятые - это делимитер для списка. Нет запятых - вынуждены будете ставить какую-то другую бамбошку (вот вы и ставите кучу угловых скобок либо аттрибуты зачем-то. Зачем столько ненужных артефактов?).

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

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

> как следствие копипастить не так уж и удобно. Шило на мыло. Ничем особо не лучше XML'а.

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


{"result":
{"records":[
{"c0":"17","s0":"","ca0":"44677","h0":"","a0":"l","c1":"Is t
{"c0":"18","s0":"","ca0":"44678","h0":"","a0":"l","c1":"Is t
{"c0":"19","s0":"","ca0":"0","h0":"","a0":"l","c1":"","s1":"
{"c0":"20","s0":"","ca0":"44679","h0":"","a0":"l","c1":"1. A
{"c0":"21","s0":"","ca0":"0","h0":"","a0":"l","c1":"","s1":"
{"c0":"22","s0":"","ca0":"44680","h0":"","a0":"l","c1":"% ch
{"c0":"23","s0":"","ca0":"44681","h0":"","a0":"l","c1":" a
{"c0":"24","s0":"","ca0":"44682","h0":"","a0":"l","c1":" b
{"c0":"25","s0":"","ca0":"44683","h0":"","a0":"l","c1":" c
{"c0":"26","s0":"","ca0":"44684","h0":"","a0":"l","c1":" d
{"c0":"27","s0":"","ca0":"44685","h0":"","a0":"l","c1":" e
{"c0":"28","s0":"","ca0":"44686","h0":"","a0":"l","c1":" f
...
...
...
{"c0":"112","s0":"","ca0":"44768","h0":"","a0":"l","c1":"k.
{"c0":"113","s0":"","ca0":"44769","h0":"","a0":"l","c1":"Sum
{"c0":"114","s0":"","ca0":"0","h0":"","a0":"l","c1":"","s1":
{"c0":"115","s0":"","ca0":"44770","h0":"","a0":"l","c1":"11.
{"c0":"116","s0":"","ca0":"44771","h0":"","a0":"l","c1":"Sig
{"c0":"117","s0":"","ca0":"44772","h0":"","a0":"l","c1":"Dat
{"c0":"118","s0":"","ca0":"44773","h0":"","a0":"l","c1":"Rec
{"c0":"119","s0":"","ca0":"44774","h0":"","a0":"l","c1":"Sig
{"c0":"120","s0":"","ca0":"0","h0":"","a0":"l","c1":"","s1":
{"c0":"121","s0":"","ca0":"0","h0":"","a0":"l","c1":"Notes",
{"c0":"122","s0":"","ca0":"0","h0":"","a0":"l","c1":"","s1":
],
"colsDefs":[
{key:"c0",label:"",className:'th',width:20,resizeable: true,
,{key:"c1",label:"B<BR/><strong>Category</strong>",width:180
,{key:"c2",label:"C<BR/><strong>2005/06 Actual</strong>",wid
,{key:"c3",label:"D<BR/><strong>2006/07 Actual</strong>",wid
,{key:"c4",label:"E<BR/><strong>2007/08 Budget</strong>",wid
,{key:"c5",label:"F<BR/><strong>08/09 Plan</strong>",width:1
,{key:"c6",label:"G<BR/><strong>Cohort Average 08/09</strong
,{key:"c7",label:"H<BR/><strong>09/10 Plan</strong>",width:1
,{key:"c8",label:"I<BR/><strong>Comments / Issue</strong>",w
],
"cols":["c0","s0","h0","v0","e0","a0","t0","ca0","c1","s1","
},
"tabs":["Checklist","Assumptions","BalanceSheet","RevExp","R
"currentTab":"0"
}

а теперь вставьте свои ХМЛьные скобки и насладитесь размером (запихнёте вы хоть в элементы, хоть в аттрибуты).

но всё это оффтопик. Как я сказал - я за протоколы - для RPC (JSON тоже крив как и ХМЛ, но хотя бы не избыточен, компактен и более читабелен)

> В мире есть утилиты помимо grep и sed. Ищите и обрящете.

обана. (на святое???)
Это униксовый форум между прочим.
(а ну да, есть вижуал и прочие)

>запятые - это делимитер для списка

Между {} они зачем?

>Для передачи данных - последний и компактнее

man gzip

>а теперь вставьте свои ХМЛьные скобки и насладитесь размером

А теперь повысьте уровень вложенности (массив списков массивов и прочее) и наслаждайтесь.

>И не путайте конфиги для чтения и правки людьми (топик) и структуру для передачи данных между процессами (JSON).

Тема как бы о конфигах была с утра, уже нет?

>ключ = значение

Наше все! Долой человеконечитаемые форматы!

Что на святое? По вашему других CLI утилит не бывает? Вот это новость!

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

Просто ХМЛ - это намного хуже даже этого (хуже для конфигов - могут быть только бинарные конфиги. Ведь топик о конфигах)

> Между {} они зачем?

JSON - нативный жабаскрипт, а не продукт теоретиков и бездельников из комитетов. Поэтому и есть кое-какие конвенции.

> Тема как бы о конфигах была с утра, уже нет?

я кстати о том-же (и JSON и ХМЛ - для RPC)

> Что на святое? По вашему других CLI утилит не бывает? Вот это новость!

это одни из основных для поисков, замещений, фильтрации.
А чем пользуетесь вы?