Билл Гейтс о свободном ПО

>XML можно преобразовать (потоком) в твой декларативный язык,
а зачем тогда xml вообще?
dom - не катит, памяти не хватит, а когда будут колбеки из SAX'a, то вам надо хранить в стеке или памяти все таги, что не закрыты. В случае правильного подхода (игра слов - здесь от "правило", rule), берём запись, апплаим её, берём другую - теперь её применяем.
И читаемо. И просто.
Кстати, я не уверен что многие парсеры будут счастливы, если я их буду кормить бесконечным стримом - начало пришло, а конец (закрывающиеся таги) - ещё в пути. Поправьте - если все это кушают.
В другом случае - это не параллельная обработка а поддержка огромных буферов - зло и трата ресурсов.

в дополнение скажу - что поэтому sed рулит на обработке больших потоков. (именно gnu sed, так как прприетарные заваливаются). Будеть трещать часами, но обработает стрим, сколь угодно большой, на пакетной обработке. Пробовали xml - получили уход в thrashing (paging) и OutOfMemоry

OutOfMemory - там мне говорили 4 Гига было полностью аллоцировано -Xmx

Причем, судя по ответам, подумать над моим комментарием они не хотят. Про инфосет никто тему не поднял...

> Пробовали xml - получили уход в thrashing (paging) и OutOfMemоry

У меня случилось то же самое. :-( При размере 6,5 Gb на примерно 3,2 Gb все вылетело...
Хотя, это может быть связано с ядром? 2.6.8 + 2 security path...
Перспективы не кажутся радужными... :-(

>> XML можно преобразовать (потоком) в твой декларативный язык, > а зачем тогда xml вообще? затем, что наконец-то монстры бизнеса договорились а более-менее общем открытом формате обмена данными.

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

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

чтобы XML не тормозил надо отключать подсветку!

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

>Хотя, это может быть связано с ядром?

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

в случае же с префиксами - это не только - набор коротеньких правил где каждый момент времени мы занимаемся одним из них, сколько и более читаемая запись глазом.
Потом в случае с xml боюсь что для применения каждого правила (какого-то пути) надо сделать проход по всем символам xml текста - для нахождения его, его аттрибутов, то-есть парсер внутренне сделает проход и проверки, что очень дорого. Хотя как выше я поднял вопрос про SAX - я не знаю уровень поддержки инкрементального парсинга в нём. Часто люди вообще не задумываются о памяти беря DOM и получают завал на больших массивах.

А, чёрт его знает... Вот, сейчас сижу, разбираюсь... Приду к каким-либо выводам - расскажу.

возьмите передачу звук-видео-дата стрима. Будем дробить всё на маленькие xml - мессаги? И получим что весь процессинг тратится не на декодер там что как-бы необходимо, а на парсинг, проверки-сравнение стрингов итд, ведь парсинг - это _очень_ дорогой процесс. Ну, понятно, что при компиляции без этого не обойтись - это делается один раз, но делать так-сказать _компилирование_ каждого xml (символьного) сообщения - имхо ненужный природе оверхед. Опять же discloser: если не появится спека xml (надо бы предложить стандарт :) где не требуется закрытия тагов, существования одного корня итд. Но тогда это просто выродится в стандартные строки (стрим из строк) где роль конца строки или разделителя выполняет не '\n' а несколько символов типа '<foo>'

А такой стандарт существует - это MIME muti-part request form
(гляньте в структуру своих мейлов с аттачментами).

короче на мой взгляд (конечно многие будут несогласны) - xml появился в годы бума IT (до 2000), когда вкладывались деньги во всё, часто пионерами выучившими какую-то одну супер-пупер панацею, не удосужившись изучить уже существующие стандарты, а почему это было сделано так 20 лет назад а не иначе, как распределяется память итд. А сейчас - он естественно будет стандартом, так как слишком много на нём завязано, много денег инвестировано, вбухано в спецификации. Лучше отстойная спецификация (стандарт) чем отсутствие его. Вот и будут его развивать. Это как случай с M$.

боже мой, что за бардак в мыслях.

XML предлагается как стандарт взаимодействия между произвольными приложениями (я имею в виду в контексте письма БГ), которые a priori не представляют о существовании друг друга. Так что на XML они могут договориться между собой о способе сжатия и формате передачи потока (ту же ASN схему можно описать на XML).

Посмотрите для примера как работает bittorrent (если не ошибаюсь, там используется стандартный питоновский XMLRRC, по крайней мере в официальном клиенте)

А откуда эти незнающие друг о друге приложения знают, что-гле лежит и какое семантическое значение у этого присланного мусора? А протокол можно описать и не используя нечитаемую иерархическую структуру. Не нравится IIOP - используйте тот-же префиксный символический подход (пример выше) и определите гораздо более ясный протокол.
Скоро в http наверное строки заменят xml-ем :)

используйте plain http и в теле (POST) - пропертя (строки) как я сказал - и будете заниматься прописыванием бизнес-логики, а не псевдо-работой по поддержке xml что само по себе - ничего нового не даёт. Если конечно вы определяете протокол (оба конца). Если вам уже кто-то шлёт в xml - тут уж не поможешь - Би-2-Би, программистам тоже надо что-то делать ;)

Полностью согласен. Жаба нужна тем, где не нужна скорость и максимальная отказоустойчивость. А где нужна - там на... не нужна жаба :-)

Знаю человека, который netflow собирал самописным коллектором на жабе. И ничего, неплохо работал.

1. XML - http://www.w3.org/XML/ 2. DTD,Schema - определяют формат документа 3. XML - древовидная БД (соответственно без рекурсии не обойтись) 4. DOM,SAX - библиотеки для обхода и работы с деревом при чем первая может изменять дерево, а вторая нет. 5. Интересный проект colorer - использует XML http://plugring.farmanager.com/downld/files/colorer4ever.far.rar 6. При чем XML к Microsoft не понимаю. 7. А БГ боится IBM и SUN, а не GNU/Linux.

Йоу! Йоу! Йоу!

Настаясчие патсаны с лора ришают сутьпы мирафых стандартоф!

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

ЗЫ: А анод идет читать про wbxml как про одну из ипостасий зюмеля потом еще раз рассказывает про гигабайтные XMLы. И неудобный парсинг.

2 anonymous (*) (06.02.2005 23:37:46)
1)хм, спасибо за wbxml - много нового появляется последние годы
2)серьёзная - это была SGML. Кому-то она показалась слишком сложной - кастрировали. Слишком много. От непонимания. Это как дос в начале.
3)в том-то и дело что деньги определяют. И увы- не самые эффективные, оптимальные стандарты. А если они есть - то уже _приходится_ вставать на уши.

2 anonymous (*) (06.02.2005 23:37:46)
и согласитесь что конфиги - это не IPC, а интерфейс с человеком и делать его трудночитаемым без единого преимущества - это не от большого ума.
Стадные инстинкты надо контролировать, особенно когда это касается технологий.

> то-есть имхо xml - как и рекурсию - надо избегать на больших задачах

чем плох tail recursion?

стек растёт полюбому - не хватит на глубокой рекурсии.

> В XML главное не формат (который вообще, строго говоря, pluggable). В XML главное - infoset. Если Ваши s-expressions могут его выразить однозначно (могут, очевидно, только надо ввести некоторые доп. соглашения) - они тоже могут носить гордое имя XML.

Речь, как я понял, шла о наиболее эффективном способе выразить тот самый infoset. Я думаю, очевидно, что существующий синтаксис этого дела довольно неэффективен (что неудивительно, ибо оно представляет собой пародию на монструозный сам по себе SGML).

А вообще, грустно все это... напоминает стародавние споры паскальщиков (и дельфистов) и сишников на тему "а у вас вот скобочки неправильной формы". =)

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

> стек растёт полюбому - не хватит на глубокой рекурсии.

Это с чего это он растет? с goto?

>Ну нахрена мне конфиг к программе в xml?
Почему бы и нет ?

>Что нормального может сказать Билл Гей...тссс ;) о свободном ПО? >По-моему не чего. Как всегда, "Вы все пид@#%сы, один я Д'Артаньян" ;)
Да, он как всегда предсказуем :)

с xml-ем немного не так. Он обычно парсируется рекурсивно. Как и лисп. Пролог - другой подход. Как и в приведённом выше декларативном описании иерархической структуры кусочками. Скрипт. Если хотите - postscript подход vs SVG. Для маленьких имиджей может ничего, а для издательского дела - не думаю что из SVG можно вытянуть огромные многостраничные тома, так как всё-же это - один xml. Хотя времена меняются и найдут безусловно решение. Но не надо было-бы и искать - если изначально не вводили не самый оптимальный способ хранения иерархической структуры. ИМХО, конечно.

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

>Я проинтервьюревал ~60 индусских XML архитекторов, бля на резюме у всех >золотые XML горы, в реалности никто не мог в SQL три таблицы соеденить, >я не говорю про то, что половина не понимала разницы между порцессом и >программой ...
Простите а что такое есть "XML архитектор" и зачем ему нужно знать как связывать sql таблицы ?

Почему бы в винде вместо реестра оракл не держать?

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

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

Название программы в студию.

Парсить XML дольше и геморройнее, чем простой текстовый конфиг. Если ты делаешь это один раз при старте программы, то это не имеет значения.

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

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

XML хороший формат, но пихать его во все дыры не нужно.

P.S. Заходим в конфиги, например, dbus и офигеваем.

Да в том-то и дело, что плевать, на самом деле (по смыслу, без деталей реализации), как оно выражено. Сила xml - в семантике. Кому-то не нравится sgml-derived syntax - пусть использует другой. Хоть .ini (хотя мне не очень понятно, как инфосет в него запихать без извращений). А вот сама мысль, что данные надо структуризовывать, причем частно более глубоко, чем на 1 или 2 уровня - это существенная мысль!

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

Ты вообще знаешь что такое tail recursion?

Это когда рекурсивный вызов идет прямо перед возвратом из функции. Т.е. к текущему стековому фрейму обращений больше не будет, и потому его можно повторно использовать. Т.е. вместо того, чтобы тупо запихать на стек параметры и адрес возврата и вызвать самого себя, просто меняем значения _своих_ параметров, и делаем goto на начало. Естественно, стек не забивается - там все время занято место, необходимое под _одну_ копию параметров и локальных переменных функции, вне зависимости от глубины рекурсии.

> Да в том-то и дело, что плевать, на самом деле (по смыслу, без деталей реализации), как оно выражено. Сила xml - в семантике.

Дык, семантика xml - это s-expressions =)

> Кому-то не нравится sgml-derived syntax - пусть использует другой. Хоть .ini (хотя мне не очень понятно, как инфосет в него запихать без извращений)

Легко =) Будет что-то типа Root.Books.Book(0).Author.Name="Foobar". Т.е. то что предлагает Anode.

> возьмите передачу звук-видео-дата стрима. Будем дробить всё на маленькие xml - мессаги?

Тормоз. Будем продолжать делать так, как это есть сейчас: разбивать на блоки/фреймы/чанки. Ты молодец, что о "звук-видео-дата" заговорил, посмотри на "матрешку" (libmatroska), там используется ebml -- "бинарная версия XML". И ничего, очень даже хорошо справляется с поточной передачей данных. ;) Разруха не в сортирах, она в головах... Достаточно научиться разумно использовать инструмент, а заставь дурака XML парсить, он и память забьет, и лоб расшибет...

Хотя, надо признать, ebml -- это очередное придумывание велосипеда: давным-давно существует стандартный ASN.1, именно для подобных целей и созданный. Описать структуру данных и использовать PER, как самый компактный, вот и всех делов. Разумные люди так и поступают. Передать "звук-видео"? Пожалуйста: H323 со товарищи описаны в ASN.1 и используют PER. Да что говорить, внутри кисок, например, вообще все структуры в ASN.1, от MAC фреймов, через IP, и до самой макушки. Про snmp я даже и не говорю.

Кстати, есть и XER -- XML Encoding Rules, как нетрудно догадаться. Специально для любителей гонять данные из/в XML. Очень удобно принять XML, XSLT его в XER, а там уже спокойно и шустро в уже описанные ASN.1 структуры.

Короче, дети, УЧИТЕСЬ, набирайтесь знаний. И не ругайте то, чего не понимаете. К сожалению, все нападки на ЛОРе, как на XML, так и на прочие технологии, очень напоминают ту самую лису, а не конструктивный спор.

что легче понять и не допустить ошибку (которая будет всегда), и что проще дебаггировать:

<Set name="Stuff">
<New class="Person">
<Arg>12</Arg>
<Set name="primary">
<New class="Education"/>
</Set>
</New>
</Set>

или

Set set=new Set("Stuff");
Person person = new Person(12);
person.setEducation(new Education("primary"));
set.add(person);

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

или как вам пример из анта

<condition property="appserver.root" value="/opt/resin/webapps">
<os family="unix"/>
</condition>
<condition property="appserver.root" value="C://resin-2.1.13/webapps">
<os family="windows"/>
</condition>

что можно было бы написать как

if(os.family==unix) appserver.root="/opt/resin/webapps"
if(os.windows==windows) appserver.root="C://resin-2.1.13/webapps"

правда на вкус и цвет...

> Короче, дети, УЧИТЕСЬ, набирайтесь знаний. И не ругайте то, чего не понимаете.

Два несовместимых пожелания. Если только разевать варежку на все, что расхваливают пиарщики, и кидаться изучать все Самые Лучшие И Универсальные Технологии - толку мало. Имхо критический анализ чужих построений (в том числе и "умных дядей") именно с целью поиска ошибок и их нещадной критики в дальнейшем не позволит наступить на те же грабли самому.

Разумеется, это должна быть критика в духе "это бяка, потому что ...", а не самобытное лоровское "зумль сукзь патамучта M$/санки/вапщевсе маздай, даеш си и унихвэй!"

;)

> что легче понять и не допустить ошибку (которая будет всегда), и что проще дебаггировать

А давай расставим отступы?

<Set name="Stuff">
<New class="Person">
<Arg>12</Arg>
<Set name="primary">
<New class="Education"/>
</Set>
</New>
</Set>

или

Set set=new Set("Stuff");
Person person = new Person(12);
person.setEducation(new Education("primary"));
set.add(person);

Вот тут я уже отдал бы предпочтение первому варианту...

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

И все-таки отступы =)

  <Set name="Stuff"> 
    <New class="Person"> 
      <Arg>12</Arg> 
      <Set name="primary"> 
        <New class="Education"/> 
      </Set> 
    </New> 
  </Set>

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

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

> а не самобытное лоровское "зумль сукзь патамучта M$/санки/вапщевсе маздай, даеш си и унихвэй!"

Ага. Значит, "дети, УЧИТЕСЬ". То есть, "критический анализ чужих построений ... с целью поиска ошибок и их нещадной критики". Приятно видеть консенсус.

> Туда же, кстати, и XSLT.

Эт ты зря.

Недостатки xml: 0. низкий функционал (предел возможностей xml & xslt --- hierarchy key-value). Т.е. всё что может xml s-expression может смеясь, обратное совершенно не верно. 1. низкая человекочитаемость. Действительно понять смысл формы (+ 2 2) гораздо проще чем <sum> <value> 2 </value> <value> 2 </value> </sum> 2. оверхед. На голом месте создаётся совершенно левый трафик (см. пример выше) 3. И вообще объясните мне пожалуйста зачем этот xml нужен. Для каких задач его следует использовать, а то куда ни посмотрю --- везде находятся более прогрессивные технологии.

Недостатки xml:

0. низкий функционал (предел возможностей xml & xslt --- hierarchy key-value). Т.е. всё что может xml s-expression может смеясь, обратное совершенно не верно.

1. низкая человекочитаемость. Действительно понять смысл формы (+ 2 2) гораздо проще чем <sum> <value> 2 </value> <value> 2 </value> </sum>

2. оверхед. На голом месте создаётся совершенно левый трафик (см. пример выше)

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

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

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

Все же внятного объяснения имеющемуся "углоскобочному" синтаксису XML пока здесь никто так и не дал...

> Ага. Значит, "дети, УЧИТЕСЬ"

Дык, учимся =)

(setf (root appserver)
      (case (family os)
        (unix "/opt/resin/webapps")
        (windows "C://resin-2.1.13/webapps")))

2 int19h
ок, ты изменяешь саму оригинальную переменную. наверное будет работать. Некошерно, правда, говорят goto. Впишут завтра в какой-нибудь верификатор - не давать добро на код, имеющий goto - к тому ведь идёт ;)