Вопос про XML и джабберы...

[nataraj]

И в Симе и в Пси, запросы, посылаемые серверу, конструируются спецуевым XML-конструктором (типа XML-парсер, только наоборот, не знаю какое правильное слово для него есть). Последовательно вызываются функции, вида "начался элемент", "в начавшийся элемент добавили атрибут", "внутрь элемента добавить текст или другой элемент", закрыть открытый элемент...

При этом не знаю как в Пси, я глубоко не смотрел, но в Симе эти функции в процессе конструирования запихивают полученную конструкцию в сокет.

В результате сам метод send() фактически ничего не посылает, а просто дозакрывает незакрытые теги...

Внимание вопрос: А зачем городить такой огород? Что мешает при отправке запроса руками вставить нужные заискейпленные и заамперсаженные значения в собранную руками XML'ку?

s="<iq"+
    "type='result'"+
    "to='"+to_address+"''+
    "from='"+from_address+"'"+
    "id='"+id+"'>"+
  "<query xmlns='jabber:iq:version'>"+
   " <name>"+client_name+"</name>"+
   " <version>"+client_version+"</version>"+
   " <os>"+os+"</os>"+
  "</query>"
"</iq>"

И потом просто запихнуть ее в сокет...

Оно возможно не столь эстетично... Но во-первых мозг съедает меньше... А во-вторых позволяет отделить код конструирования запроса от кода посылки, чего тоже очень хочется...
И в каком-то смысле более удовлетворяет принципу KISS(Keep It Simple Stupid)

Очень хочется понять какие бонусы дает тот вариант, который применен сейчас в симе и пси... Ведь зачем-то это делалось!

ЗЫ. Я просто сейчас подошел к переписыванию этого куска, и хочу понять, следовать ли традиции, или же выпендрится...

Comments

[vitus_wagner]

Потому что оно на С++ написано. Этот язык способствует тому что разработчик начинает левой ногой через правое ухо гланды вырезать.

То что ты написал выше - код, подходящий для Perl (c точностью до замены + на .). python, ruby и т.д. Но не для плюсового stdstring.

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

[slobin.livejournal.com]

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

... Это неправильные молнии - они делают неправильный гром ...

[shaplov.livejournal.com]

То что ты написал выше - код, подходящий для Perl
Ну еще бы... последние пять лет дают о себе знать...

то рекомендую взять libxml с какой-нибудь плюсовой оберткой,
Вот чего я боюсь, так это сколько оно будет жрать памяти и процессора... У некоторых пользователей, судя по слухам, в контак листе записи меряются тысячами... И мы при выходе в онлайн каждому из них шлем jabber:iq:version запрос... Структура от которого весит в памяти до тех пор пока не придет ответ...

Но вот чего точно хочется, так это абстрагировать процесс генерения xml'ки, от процесса ее отправки... А там сейчас оно объединено в одно большое [censured]...

Видимо разнесу процесс генерации и отправки, и пусть пока генерация будет в perl-way... Ее отдельно будет проще переписать, чем распутывать этот комок змей монолитный...

[gegmopo4.livejournal.com]

Но вот чего точно хочется, так это абстрагировать процесс генерения xml'ки, от процесса ее отправки... А там сейчас оно объединено в одно большое [censured]...

Зачем? Если одно никогда не встречается без другого, то вполне естественно объединить эти две процесса и рассматривать как одну операцию.

[shaplov.livejournal.com]

Зачем? Если одно никогда не встречается без другого, то вполне естественно объединить эти две процесса и рассматривать как одну операцию.

Видишь ли, код -- живой организм, который изменяется и трансформируется в процессе жизни...
И такую трансвормацию удобно проводить, когда точно знаешь, что getXML выдает текст XML'ки, и к черту подробности, каким именно способом... Тогда можно спокойно рефакторить ту часть, которая отправляет это все в сокет...
А если оно содержит кучу завязок друг на друга, то это надо еще хитро изворачиваться, чтобы изменить ту часть которую надо, так, чтобы не порушить остальное... Если это вообще возможно...

[gegmopo4.livejournal.com]

То что ты написал выше - код, подходящий для Perl (c точностью до замены + на .). python, ruby и т.д. Но не для плюсового stdstring.

Если имеется в виду инкрементальная сборка строки, то для этого есть std::ostringstream. Или какая-то специально написанная обёртка, учитывающая специфику задачи, как в данном случае и есть похоже.

На самом деле причина, почему этот подход применяется в C++ и не применяется (или редко применяется) в Perl, Python, Ruby проста — в C++ это возможно сделать, а в Perl, Python, Ruby — или невозможно или не так удобно. Ну и выигрыш байтов/тактов съестся языком.

[slobin.livejournal.com]

"Потому что оно на С++ написано." Всё языки делятся на две большие группы -- лисп и все остальные. Вряд ли моя реплика поможет хозяину журнала, но удержаться не смог -- the LISP way:

(load "sxml2xml.lsp")

(setq to_address "a&b" from_address {"cd"} id 456
      client_name "<clmn>" client_version "per'ver" os "os/2")

(setq pattern '(iq (@ (type "result")
                      (to to_address) 
                      (from from_address)
                      (id id))
                   (query (@ (xmlns "jabber:iq:version"))
                          (name client_name)
                          (version client_version)
                          (os os))))

(sxml2xml print pattern 2)

Результат:

<iq type="result" to="a&amp;b" from="&quot;cd&quot;" id="456">
  <query xmlns="jabber:iq:version">
    <name>
      &lt;clmn&gt;
    </name>
    <version>
      per&apos;ver
    </version>
    <os>
      os/2
    </os>
  </query>
</iq>

Правда, в этой реализации лиспа есть из коробки XML-парсер, но почему-то нет XML-эмиттера. Ну то есть я знаю, почему: потому что при его написании я уложился в 999 символов. ;-) Спасибо хозяину журнала и автору предыдущей реплики за задачку на потренироваться. (Примечание: предыдущую версию этого комментария я удалил -- там была небольшая ошибка (я невнимательно прочитал исходный сишный текст и запутался в кавычках и апострофах)).

... Удивительное - рядом, но оно запрещено ...

[slobin.livejournal.com]

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

<iq type="result" to="a&amp;b" from="&quot;cd&quot;" id="31415">
  <query xmlns="jabber:iq:version">
    <name>&lt;clmn&gt;</name>
    <version>per&apos;ver</version>
    <os>os/2</os>
  </query>
</iq>

Интеллект обошёлся ещё в 118 символов. ;-)

... Знаменитая писательница на заборе ...

[beldmit.livejournal.com]

ИМХО, следовать. В сокет оно пихать не может все равно до закрытия всех тегов. А если следовать - тебе не приходится думать об их закрытии.

[vitus_wagner]

Как это не может - еще как может. Что ему, спрашивается помешает. Ему достаточно где-то иметь стэк незакрытых тегов. Только имена. А всё остальное - атрибуты, текстовые элементы, комментарии если есть, можно сразу пихать в сокет.

[shaplov.livejournal.com]

Посмотрел: По факту он накапливает все это в буфере, и потом по команде send этот буфер таки пишет... И все это в объекте socket... :-/

[gegmopo4.livejournal.com]

Оно возможно не столь эстетично...

Это — главная и единственно важная причина. Можно конечно и все параметры отдельно эскейпить и перекодировать, и за балансировкой тегов следить (особенно когда структура XML статическая). Но... неэстетично.

[wrar.livejournal.com]

Да читал я эту запись, читал.
Но проблему не понял.

[shaplov.livejournal.com]

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