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

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


да блин, чем вам файловая система (иерархическая база данных) - не иерархия?

А MIME протокол, которому сто лет в обед, сколько угодно файлов шлёт - и нечего.
man MIME.

Сериализация и десериализация всего - это ненужное повышение энтропии.
Ну храните все свои данные в клобах-блобах, а не в файловой системе. Легче будет?

Запихивая в хмл - делаете то же самое!

Всё, кончаю оффтопить (вот ведь как кривизна и безрукость заводит).

Только о конфигах отныне.

Чтобы вы поняли правильно мой последний месседж, таки добавлю:

имеется в виду - передача иерархической структуры - как пути.

MIME же - для более сложного (когда много файлов).

А уж на файлы разбивайте и структурируйте внутри - как удобнее и четаемее.

Всё будет лучше.

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

Ну так и пользуйте его eval() жабаскриптами. Хотя даже для них, вроде бы, вводят нативное, не требующее eval()'а.

>> Тема как бы о конфигах была с утра, уже нет?
>я кстати о том-же (и JSON и ХМЛ - для RPC)

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

Посмотрите на xmlstarlet.

>да блин, чем вам файловая система (иерархическая база данных) - не иерархия?

Используйте её, если у вас нет других способов. Это не делает ваш способ лучше.

>А MIME протокол, которому сто лет в обед, сколько угодно файлов шлёт - и нечего.

Это вы вообще о чём сейчас?


>Ну храните все свои данные в клобах-блобах, а не в файловой системе. Легче будет?

Годный вброс. Только вот XML это не блобы, так что мимо.

Много файлов можно передавать по всякому, но это не тема данного обсуждения, вобщем-то.

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

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

А юникс-тулы устоялись, отточились и позволяют всё и давно.

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

да, я зарёкся. Давайте уж только о конфигах.

xmldiff ещё есть, но мне пользоваться им не доводилось.

>А юникс-тулы устоялись, отточились и позволяют всё и давно.

Эти тулсы тоже есть не со вчерашнего дня. И тоже CLI. Вот ведь неожиданность! Или CLI уже не юникс вей? Ну тогда используйте grep, awk, sed, ini-файлы, никто вас не заставляет лично использовать XML.

>Так учите кошерный юникс сразу.

Вопросы кошерности меня беспокоют меньше всего :}

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

Значит я не человек. Я очень легко понимаю XML. Слава робатам! :}

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

> Вопросы кошерности меня беспокоют меньше всего :}

ну не скажите... Бытиё опреедляет сознание. Нельзя жрать всякую нечисть и пить из лужи и писать красивые полотна (Да просто сдохнуть можно от бактерий и дизентерии). все поступки должны быть обдуманы. Например, завтра вам выставят иск за использование хмля. А мы вам опять скажем: "ну предупреждали ведь!"

>Например, завтра вам выставят иск за использование хмля.

В России то? :) Если так рассуждать, то иск и за использование всего остального влепить могут.

> Значит я не человек. Я очень легко понимаю XML. Слава робатам! :}

проблема ещё в том - что эти люди часто выбрасывают роботов на свалку истории...

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

SkyNet обо всём позаботится, не беспокойтесь :}

>В России то? :) Если так рассуждать, то иск и за использование всего остального влепить могут.

а теперь попробуйте подняться над всем этим, посмотрите сколько лет юниксовым тулам и как они _уже_ хорошо работают, и скажите: "а оно вам надо"? (чёта опять ёжики вспомнились)

>SkyNet обо всём позаботится, не беспокойтесь :}

мы захардкодим в железо 3 принципа робототехники

Надо. Тут вот люди и про xml-подобный HTML говорят, что, мол, устарел и не нужен, а поди ж ты, используют! Для всего есть своё место. И для XML'а в том числе.

P.S. Не тронь ёжиков, они хорошие :}

Выведем 4ый ;)

надо идти. Подумайте над вопросами, которые я поставил быше. Честь имею.

дауж -- XML без namespace -- полная чушь...

почти как и не XML уде получается

в такой недо-XML можно наверно только конфиги хранить... но вот проблемато какая -- конфиги лучше хранить вообще не в XML

>Ты уверен, что это нужно хранить в конфиге?

стопудова. конфигурация интеграции

оже мне новость. Может, мне тоже свой древний курсач зарелизить? (Недопарсер на плюсах — http://home.sunchaser.info/articles/src_mycpp_xml.html )

проктоXML?

> xmldiff ещё есть, но мне пользоваться им не доводилось.

и слава богу, потому что он не аналогичен diff, по его выводу невозможно понять какое значение было раньше, до исправления:
$ xmldiff a.xml b.xml
[append-first, /,
<xml name="значение"/>
]
[remove, /xml[2]]

$ cat a.xml
<xml name="старое">
</xml>

$ cat b.xml
<xml name="значение">
</xml>

А xmldiff-xmlrev не помогает? Правда там написано что-то про html документ.

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

> проктоXML?

libanal.so

Купил подсыпку для кота под названием "Коту под хвост" =)

>когда селфоны будут поддерживать ssh

Уже лет пять как.

>А теперь повысьте уровень вложенности

Уровень вложенности больше 2-х в структуре данных почти всегда означает неверный подход к решению задачи. А на два уровня даже YAML не нужен.

Объявить «нам оно не нужно» это всякий может :}

подозреваю, что аналогичный по функционалу парсер на flex'е можно уложить в 50 строк

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

Если конфиг этого не требует, то +1, разумеется.

Я вроде бы однажды просил. Ладно, прошу ещё раз: опиши пример, когда в _конфиге_ (не путать с rc) _невозможно обойтись_ без многоуровневых многократно вложенных друг в друга структур с прочими сложными связями, для чего потребовался бы json или xml (да, конфиги трансмишна на json'е и конфиги хала и фонтконфига не просто ужасны - они полное говно и чрезвычайно избыточно. Фтопку роботов)

Кого ты просил не знаю, спроси того, кого просил раньше :}

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

Потому что случаи всякие бывают. А говорить «xyz не нужно» это мы все можем :}

> Потому что случаи всякие бывают

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

Раз в сто лет кому-то нет да и нужна бывает древовидность :)

Попрошу пример конфига, в котором необходима древовидность (в размерах больше, чем в ini файле) в студию.

В ini файлах уже есть древовидность? Даже простое меню требует дерево.

> В ini файлах уже есть древовидность?

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

Не то, чтобы это было кому-нибудь особенно нужно, но оно есть.

> Даже простое меню требует дерево.

Описывать меню в конфиге? Даже если пришёл в голову такой изврат, то это легко делается обычным текстовым файлом. man .fvwm2rc

>Описывать меню в конфиге? Даже если пришёл в голову такой изврат

Вы KDE давно видели? :)

>man .fvwm2rc

Да да, ещё fvwm вместе с KDE ставить :} А на словах?

> Вы KDE давно видели? :)

niels:/tmp$ konqueror --version
Qt: 4.5.2
KDE: 4.2.4 (KDE 4.2.4)
Konqueror: 4.2.4 (KDE 4.2.4)

> Да да, ещё fvwm вместе с KDE ставить :} А на словах?

niels:/tmp$ du -h ~/.fvwm2rc
16K /home/sergey/.fvwm2rc

З.Ы. У меня ещё и WindowMaker есть ;)

~/.kde/share/apps/${appname}/${appname}ui.rc ;)

Да я про структуру того rc, как оно там хранится? :}

> ~/.kde/share/apps/${appname}/${appname}ui.rc ;)

niels:/tmp$ ls ~/.kde/share/apps/konsole/ | grep ui | wc -l
0
niels:/tmp$ ls ~/.kde/share/apps/konqueror/ | grep ui | wc -l
0
niels:/tmp$ ls ~/.kde/share/apps/kopete/ | grep ui | wc -l
0
niels:/tmp$ ls ~/.kde/share/apps/kmail/ | grep ui | wc -l
0
niels:/tmp$ ls ~/.kde/share/apps/knode/ | grep ui | wc -l
0

Надоело ;) Впрочем, я не отрицаю того, что в xml можно описывать меню (или иную часть конфига). Мне просто непонятно, зачем оно там нужно.

> Да я про структуру того rc, как оно там хранится?

Если опустить детали синтаксиса, то там нечто типа

main menu
submenu1
submenu2
...

submenu1
item1
item2
...

итд.

Возможно вы просто не пользуетесь KDE ;)

dolphinui.rc: http://pastebin.ca/1531340

>Если опустить детали синтаксиса, то там нечто типа

А если ещё один уровень вложенности? Такое часто случается. Тоже не слишком удобно :}