Протоколы прикладного уровня: Jabber/XMPP часть1

[ukko]

Спасибо, очень актуально…

[merlin-vrn]

не знаю, как на jabber.ru, но вообще сервер ejabberd (у меня стоит он) ругается на ваш xmlns:stream в самом первом заголовке потока. Если указать namespace как он сам уазывает — с http — всё работает:

И Kopete шлёт такой же точно xmlns — с http.

<stream:stream xmlns="jabber:client" to="jabber.rterm.ru" version="1.0" xmlns:stream="http://etherx.jabber.org/streams">

И ещё, в следующий раз, когда будете xml постить, сделайте так, чтобы вокруд значений параметров двойные кавычки не превращались в ёлочки. Они там не в тему :)

[seriyPS]

Видимо злобный парсер сгрыз хттп:// (а он там был)
Проставил везде тег code — вроде нормально стало. Кавычки поправлю.

[fleshy]

Вот спасибо! как раз хотел попробовать реализовать собственную jabber-либу и бота для конференции до кучи

[seriyPS]

Свою либу писать вовсе не обязательно, т.к. их и так куча xmpp.org/software/libraries.shtml а вот бота — это да, это запросто.

[fleshy]

минимальный обвес для бота я уже реализовал на jabber-net для C#, просто интересно разобраться как оно все-таки работает унутре

[bogus92]

Если бы кто-то такой же мануал и для http-bind написал…

[vosi]

так там ± тож самое, только в боди окружено, и первый запрос с большим количеством параметров
вот почитайте
xmpp.org/extensions/xep-0206.html
xmpp.org/extensions/xep-0124.html

[chiaroscuro]

[trolling][irony]XML это круто, необычайно круто. Особенно для сетевого протокола поверх HTTP.[/irony]

Автор, Вы не заметили, что Ваша статья чуть менее чем полностью состоит из XML? :)[/trolling]

PS а вообще жаль. этот xmpp сильно over-engineered.

[seriyPS]

Насчет over-engineered согласен, но это сделано ээ… для гибкости и расширяемости… А она, в принципе, на практике часто применяется (транспорты те-же)
В принципе, включение сжатия трафика частично поможет решить потенциальные проблемы.

[chiaroscuro]

> Насчет over-engineered согласен, но это сделано ээ… для гибкости и расширяемости…

4.2. Расширяемость бывает разная. XML расширяем только на уровне вкладывания узлов в другие узлы, а обработку этого расширенного богатства все равно придется делать в программе.

> В принципе, включение сжатия трафика частично поможет решить потенциальные проблемы.

На спичках экономим?

XML = Extensible Markup Language. Особое внимание прошу обратить на слово markup. Нет, конечно, можно шурупы забивать молотком, но нафига?

OTOH даже если и пользоваться XML не по назначению («а чо, так ведь все районные сантехники делают»), то все равно вопрос: нафига?

-К.О.

PS ох, школята опять минусуют

[voituk]

Зря вы про over-engineered. Сравните с SOAP — полюбите Jabber за простоту и логичность.
Возможно вы имели ввиду излишние обьемы трафика — ну так это решается банальным сжатием (правда и клиент и сервер должны его поддерживать)

[voituk]

+1 :)
Я всегда думал что SMTP/POP3 с телнета — извращение.
Но автор развеял мои комплексы по этому поводу :)

[flashvoid]

Большое спасибо. Буду ждать продолжения.

[seriyPS]

Кстати, пользуясь случаем хотел спросить насчет DIGEST-MD5. Может кто-нибудь проконсультировать?
Не нашел толкового описания как вычисляется response и rspaut tools.ietf.org/html/rfc3920#section-6.5
В препарированной мной для написания статьи библиотеке не было поддержки этого метода…
Конечно, в любом случае разберусь, но может у кого есть доп. информация?

[OLS]

www.faqs.org/rfcs/rfc2831.html
п. 2.1.2.1

?

[OLS]

P.S. rspauth там же в п.2.1.3

[seriyPS]

Спасибо, но это то-же, что и tools.ietf.org/html/rfc2831#section-2.1.3 (который указан в списке «литературы»)
В него я сходу не въехал к сожалению)

С response уже разобрался, с rspauth продолжаю втыкать…

[seriyPS]

Все, вопрос DIGEST-MD5 закрыт…

[olegi]

Серия постов для сотрудников mail.ru? :-)