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

> Абсолютно нереальная вещь для XML. Боже мой - фантастика.

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

>Серьезно? Можно тогда раскрытие слова семантика в студию плз и как это парсер ака синтаксический анализатор проверил семантику.

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

>На уровне тараканов в голове.

Тебе нравится, когда пустое пространство забито синтаксически незначащим мусором?

>Никто не мешает просто убрать лишние скобочки и кавычки.

Тебе что текст вставить в 5 строк чтобы ты их не убрал?

>И в глазах не рябит

Когда в глазах рябит - надо к окулисту обращаться.

Сам питоню. Вот тогда второй вариант: # Окошечко раз window=window1 heigth=100 width=100 url=http://url

# Я маленькое окошечко window=window2 heigth=-1 width=-1 url=фигвам

Блииин

Сам питоню. Вот тогда второй вариант:
 # Окошечко раз
window=window1
heigth=100
width=100
url=http://url
# Я маленькое окошечко
window=window2
heigth=-1
width=-1
url=фигвам

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

ИМХО это очевидно. В дополнение к тем ошибкам, которые можно сделать в самом конфиге добавляются ошибки при наборе тегов.

Ещё раз вопрошаю: тебе нравится смотреть на ничего не значащие символы, суть являющиеся избыточными раделителями?

Ладно, видимо сегодня мне не дождаться примера программы, которой _необходим_ xml в конфиге.

Пойду посплю, вернусь утром.

Может хоть тогда тут будет ответ?

> Я сказал, что можно получить то же, не тратя дополнительных ресурсов и абсолютно не теряя удобства

Перечисли дополнительыне ресурсы которые были бы потрачены.

>Парсер нагиоса проверяет корректность связей объектов.

В каком месте тут семантика?

Для справки семантика это вот:

resolution=640x480
location=654,100 //oops error location is out of resolution.

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


Хватит уже нести сказочный фееризм про универсальные чудопарсеры валидирующие семантику.

>Сам питоню. Вот тогда второй вариант:

Тема не раскрыта. Не раскрыта она в области: как мне найти атрибуты относящиеся к окну. Абстрактно: твой конфиг position dependent раз, должен быть абсолютно предсказуем по значениям - 2 (то есть пользователь не может определить 3 из 4х значений окна - точнее мне нужно будет проверить ручками наличие всех значений, а не пробежаться по наличиствующим и выставить их). То импликативная сложность о которой я говорю - конфиг неозднозначный по виду.

Пример

<config>
<window width="100" height="100" url="http://google.com">
<window width="100" height="100" state="maximized" url="http://google.com">
<url>http://google.com</url>
</config>

Допиши изменения и увидишь.

>ИМХО это очевидно.

То есть регэкспы писать проще чем стихи пушкина. Ага-да.

Отлично, тогда скажу так. Парсер они взяли. Семантический анализатор написали (он им в любом случае нужен). Основной код написали. В одном случае срабатывают все 3 компоненты, в другом случае (-v) только 2. Мы не тратим дополнительных ресурсов на валидацию чего бы то ни было - мы выполняем валидацию тем кодом, который отрабатывает в любом случае. В случае использования XML нам нужен левый код, который будет сверять правильность конфига с XSD (которую ещё написать надо!), а потом только отработает наш семантический анализатор. Мы затратили время процессора, память, место на диске и наши глаза и пальцы на написание лишних разделителей (скобочек и кавычек). Не получили при этом ни шиша. Вопрос - где _необходимость_ использования XML?

>Ещё раз вопрошаю: тебе нравится смотреть на ничего не значащие символы, суть являющиеся избыточными раделителями?

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

Да, конфиг позиционный. Но это как бы логично, что после объявления окна описываются его параметры. И необязательно указывать все:

(param=value, lex - param, val - value)

if lex == "window":
  win = val
  lex,val = getNextLex()
  while not lex == "window":
    wind_array[win,lex] = val
    lex,val = getNextLex()

Как-то так (правильность кода не гарантирую)

А добавлять объект с именем, равным имени параметра другого объекта - несколько некрасиво. В конце концов, даже эту ситуацию можно обойти, воспользоваашись синтаксисом:

object=window
name=...

object=url
url=...

Естественно, при этом object получается ключевым словом, его нельзя использовать в качестве имени параметра. Но кашмар, кашмар, в любом ЯП есть список зарезервированных слов

Да потому что у тебя скобочки и кавычки можно опустить, оставив разве что признак начала описания нового объекта. И всё. Они ничего не значат. Фактически, это просто разделители

>В случае использования XML нам нужен левый код, который будет сверять правильность конфига с XSD

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


> (которую ещё написать надо!)

А правила для конфига нагиоса написать не надо? Где мне скачать этот 
чудомодуль телепатии который из формата ключ значение или ключ скобки 
значения вычисляет какие именно ключи и какие значения должны быть.

>Мы затратили время процессора, память, место на диске

Гдле мне взять эту чудо либу которая проводит валидацию конфигов без 
использования процессора и памяти.

>написание лишних разделителей (скобочек и кавычек)

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

<window name="Ha-Ha" width="100" height="100"/>

window:{
 name: "Ha-Ha" 
 width: "100"
 height: "100"
}

Считай символы, математик. Если вычесть чистые данные: 6 vs 12 символов не считая переносов строк за XML.

>А добавлять объект с именем, равным имени параметра другого объекта - несколько некрасиво.

Нихрена себе. Для каждого URL свое имя?

>object=window
name=...

object=url
url=...

>Естественно, при этом object получается ключевым словом, его нельзя использовать в качестве имени параметра.

мазефакингод. и эти люди рассказывают о лишних скобках! Двайте вы вдвоем сядете и напишете на этом ужасе то что я написал в 3 строчки и будете считать символы и все расказывать про краткость и лишние слова.

>Фактически, это просто разделители

Разделители для того и нужны чтобы разделять - они значимы.

Ты, видимо, меня не понял. Я говорил о том, что в работу придётся включать когд этого самого валидирующего парсера, но который будет варидировать структуру более сложную, чем с одним возможным разделителем. Правила семантического парсинга конфига писать придётся в любом случае, и работать этот код будет также в любом случае. И место на диске и всё прочее она будет тратить в любом случае. А код парсера, который валидирует XML, жрать ничего не будет, если не использовать XML.

И эта, зачем числа в кавычки заключать?

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

Несколько типов разделителей, следующих друг за другом, не нужны

А ещё к моему второму варианту можно добавить питоньи инденты. Проблема отличания свойств от объектов пропадает

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

>Я говорил о том, что в работу придётся включать когд этого самого валидирующего парсера,

parser.setShema("url://to.schema")

Это весь код который надо включить.

>И эта, зачем числа в кавычки заключать?

man JSON RFC.

>Я про краткость ничего не говорил.

Ах уже не сестра.

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

Раскрой тему мусора если символов помимо данных в JSON больше? Вон там простой пример - что тебе мусором кажется? </>? Не мусорнее чем :{}.

>Как бы данные надо выносить из конфига, конфиг - это конфиг, а не база данных.

В конфиге хранятся данные о конфигурации. База данных не нужна.

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

>Несколько типов разделителей, следующих друг за другом, не нужны

О как пошло! :{ - сколько? [пробел]{ [пробел]} ?сколбко?

К стати я там прогнал с JSON - забыл пропущенные запятые - добавь еще 
2 символа. Как там на счет запятых?

В либконфиге вообще ; используется.

Вот пример из libconfig.

window: {
         title = "My Application";
         size = { w = 640; h = 480; };
         pos = { x = 350; y = 250; };
       };

Ну что - будем считать символы и последовательности ненужных разделителей?

Аргументы все смешнее и смешнее.

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

>А ещё к моему второму варианту можно добавить питоньи инденты. Проблема отличания свойств от объектов пропадает

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

>, где значением некоторых ключей является путь к файлу и формат (pcre, cidr и т.д.) этого файла

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

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

Segmentation fault.

Чини парсер :)

Зачем валидировать структуру конфига ценой роста накладных расходом, когда можно отвалидировать вообще конфиг на все возможные корректности без какого-бы то нибыло изменения кода?

>JSON тоже не лучшее решение для конфига. ....И всё это в 90% случаев плюсов никаких не даёт,

И это все присуще любой конфигурационной либе из предлагавшихся в качестве альтернатив.

Так что пока мы пришли только к одному заключению - рулят domain specific hand made конфиги. А все остальные более менее равнозначны. Да вот незадача - такие конфиги дорого разрабатывать - и потому их чем дальше тем меньше.

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

ЕОНУ(еще одно необоснованное утверждение).

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

Ты там то пробовал сделать ту фантасмагорию о которой говоришь?

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

Поэтому наш выбор - тяжёлая избыточная стрктура

> ЕОНУ(еще одно необоснованное утверждение).

Vietse Venema, IBM для тебя не аргумент? Авторы сквида - не аргумент? Если покопаться, то ещё можно примеров нарыть. Best practice, не более. Правка настроек не затрагивает данные

nagios -v. Устал уже повторять. --dry-run у кучи утилит. Они это _уже_ сделали

>Правка настроек не затрагивает данные

Что такое данные?

Ладно, надоело. Уже 2 обсуждение заканчивается ничем - так никто и не обосновал необходимости применения именно XML в кофигах, как никто не обосновал необходимости неиспользования XML в конфигах. Предлагаю в очередной раз пнуть разработчиков HAL и слепых последователей веры энтерпраиза и разойтись спать, а то сегодня на работу

>nagios -v. Устал уже повторять. --dry-run у кучи утилит. Они это _уже_ сделали

Ага - ты смотрел как они это сделали не? ТИЫ вообще писал хоть одну большую конфигурируемую систему? А то аргумент "уже сделали" напоминает что "молоко уже в пакетах - коровы не нужны".

То, чем программа оперирует, но что не влияет на её алгоритм. Соответственно, настройки - то, что изменяет работу алгоритма, но не является объектом операций

Я знаю, что происходит при запуске нагиоса с ключом -v. Этого достаточно. И да, аналогия вопиюще некорректна. Доброй ночи

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

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

ну тут какая проблема. если ты пользуешься тулом для работы с хмл то хорошо бы что бы этот тул умел всё что связано с данной задачей (работать с хмл). а разбираться как работает эта хрень только ради того чтобы на 0,0001% быстрее читать конфиги + набивать шишки выясняя что она даже простейшие вещи не умеет (<xml>test</xml>).

Вот реальный пример - одна и та-же конфигурация:

log4j.properties: -------8<-------- ### direct log messages to stdout ### log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.Target=System.out log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n log4j.rootLogger=debug, stdout -------8<--------

то-же через ваш кривой хмл:

log4j.xml -------8<-------- <?xml version="1.0"?> <log4j:configuration> <appender name="stdout" class="org.apache.log4j.ConsoleAppender"> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{ABSOLUTE} %5p %c{1}:%L - %m%n"/> </layout> </appender> <root> <priority value="debug"></priority> <appender-ref ref="stdout"/> </root> </log4j:configuration> -------8<--------

сорри, сбил форматирование:


Вот реальный пример - одна и та-же конфигурация. Вам судить - что легче и надёжнее (размер - тоже не в пользу ХМЛ):

log4j.properties:
-------8<--------
### direct log messages to stdout ###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
log4j.rootLogger=debug, stdout
-------8<--------

то-же через ваш кривой хмл:

log4j.xml
-------8<--------
<?xml version="1.0"?>
<log4j:configuration>
<appender name="stdout" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ABSOLUTE} %5p %c{1}:%L - %m%n"/>
</layout>
</appender>
<root>
<priority value="debug"></priority>
<appender-ref ref="stdout"/>
</root>
</log4j:configuration>
-------8<--------

а теперь напишите мне на ХМЛ аналог следующего с такой же скоростью:


------------8<------------

#
# notice - how beautiful the plain 'greppable' config is and how bad xml analog of it!

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.rootCategory=DEBUG, stdout, FILE

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.Threshold=DEBUG


log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=ais.log
#log4j.appender.FILE.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
log4j.appender.FILE.layout.ConversionPattern=%d %-5p [%c] %m%n
log4j.appender.FILE.MaxFileSize=100000KB
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.MaxBackupIndex=3
log4j.appender.FILE.Append=true
#The Threshold used for file logging
# Put ERROR in production
log4j.appender.FILE.Threshold=ERROR

#suppress Jetty debug and info logging
log4j.logger.org.mortbay=WARN

------------8<------------

а затем - я могу послать - в 3 раза больше, с SMTP и пр. аппендерами.

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

Давно понял - с ХМЛщиками о красоте и эффективности спорить бесполезно.
Они вымрут сами, как и вендузятники.
Со временем.
(Юникс тулы например - не вымери, как показывает практика и успех линукса).

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

>ТИЫ вообще писал хоть одну большую конфигурируемую систему? А то аргумент "уже сделали" напоминает что "молоко уже в пакетах - коровы не нужны".


вопрос не ко мне, но отвечу.

я писал. В сложных системах конфиг - DSL. Я делал свои грамматики, понятные бизнесу. Бизнес-аналисты не смогут писать на регекспах. Но парсер преобразовывал в конечном итоге правые части правил (рул-енджины) - в конечном итоге в категории, регекспы, SQL итд.
Но что здесь важно - это то что правила (в конфиге, модифицируемые людьми) должны быть __простые__!

Вы дадите бизнес-юзерам многостраничные ХМЛ, где чтобы понять контекст - надо мотать страницы? А если скроете ХМЛ гуёй - это уже не будет конфигом (топик - о конфиге - текстовом файле, модифицируемом юзерами).

Поэтому ХМЛ - это не текст, это - ГУИ. То что некоторые программисты привыкли с ним работать - не делает его текстом, в нормальном смысле слова.

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

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

Не путай 2 типа парсеров:
один - парсер пропертей (2-3 делимитера достаточно) - для чтения конфига и сохранения в хеш. На Ц пишется от нескольких часов до дня (смотри aisconfig по ссылке выше). Ты ХМЛ хедлеры будешь дольше прописывать и всё необходимое (правка зависимостей в билд-скриптах итд итп). На жаве - вообще Properties - из коробки.

Второй - это парсер значений, который может быть и DSL-парсером, или в простейшем случае списков - просто парсером CSV (в жаве String.split()). Если парсер правой части нужен вообще.

ХМЛ - виндовоз-вей ещё и потому - что все случаи жизни хотят впихнуть в 1 функциональность и получают - "плохо" всегда и во всём.

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

И последнее

Для меня показатель хорошего дезайна конфигов - это максимально-возможная простота модификации тесктовых файлов юзером, с наименьшим количеством ненужных артефактов (будь то DSL или мапы или их комбинации в разных файлах и оба подхода - в одном файле). ХМЛ имеет слишком большое количество артефактов "технология для технологии", как я называю.
Впихивание же сложных вещей в ХМЛ - это игнорирование юзеров программером, который думает только о себе (научившимся пользоваться каким-то одним тулом и не хотящим упрощать задачу и говорить на бизнес-языке, думать о юзерах).
Как правило - неквалифицированным программистом, и не подозревающим что для сложных конфигов можно использовать и lex/flex/yacc/bison/antlr/javacc и это сэкономит массу времени (если речь идёт о действительно сложных конфигах, котрые трудно впихнуть в простые мапы/проперти, что тоже questionable;), но не будем затевать здесь этот спор.

>То, чем программа оперирует, но что не влияет на её алгоритм. Соответственно, настройки - то, что изменяет работу алгоритма, но не является объектом операций

Можно узнать какое практическое значение имеет сей фееризм?

>Вам судить - что легче и надёжнее

Второе - очевиднее.

И да - разница действительно существенная 304 vs 340 символов. Я потрясен.