Почему от него начинают отказываться? Google, потом втентаклик. Изобретают свой велосипед? Чем XMPP плох?

NIH

Почему при том, что так много клиентов, они так и не научились работать с jingle нормально (почему-то каждый клиент по-своему)?

да нормально они с ним работают.

Почему от него начинают отказываться? Google, потом втентаклик.

Vendor lock-in.

У XMPP есть фатальный недостаток.

от него начинают отказываться? Google, потом втентаклик.

А что за новость про гугл?

Ну там с бинарными данными проблемы, так как xml не позволяет изпользовать ряд симоволов (требует энкодирования), то бинарные данные перегоняют в base64, что сильно увелиивает их в размере.

Hangouts вместо gtalk.

Гугл запилил вой Hangouts вместо-то google talk и работает это уже не через xmpp, а в скором будущем xmpp вроде как отключат вообще в гугл аккаунтах.

Не читал дальше топика

http://about.psyc.eu/XMPP#Technical_Issues_in_Jabber

Писал сервер xmpp — протокол полная хрень на двух гигантских rfc. Я не знаю в каком надо быть состоянии чтобы такой крэп на сотни страниц выдать для простой пересылке сообщений, обменом контакт-листа и уведомлениями о статусе. И это считанные проценты от полного функционала xmpp. Это помимо того что для некоторых вещей аля пересылка файлов есть ворох несовместимых rfc.

Очень много опциональной фигни. Или client _should_ do this, server _should_ do that. Вот это should по rfc означает что «хорошая имплементация так сделает, но это не обязательно». Вот это вот «гибкость» настолько раздула кол-во возможных состояний протокола что я тупо забил.

Есть вещи которые по стандарту верны, но могут не работать. Твой мессенджер поддерживает XMPP если у него нет проблем с самыми популярными серверами (аля openfire). Очень часто натыкался на то что что-то какие-то вещи с клиентами не работали, хотя по стандарту. Приходилось сидеть и медитировать на логи сессий, например, gajim и приводить к виду который они понимают.

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

Может быть слать громоздкие XML по сети - прошлый век, и лучше слать JSON/YAML

Улучшил ситуацию, ага (^ ^)'

Может быть слать громоздкие XML по сети - прошлый век, и лучше слать JSON/YAML?

На вкус и цвет. И то, и то требует base64/uuencode для бинарных данных.

Почему от него начинают отказываться?

Сложный. Аудио/видео считай не работает. Файлопередача через задницу. Плохо работает поверх HTTP. Неразбериха со стандартами. Просто морально устарел.

Уже придумали аналогичный протокол обмена сообщения?

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

Или стоит изучить XMPP получше самому

Не стоит.

Или этим стоит заняться?

Сделать _качественный_ и продуманный протокол очень сложно, нужно учесть кучу нюансов. А просто чятик с http pool - элементарно.

и написать очередной свой клиент, с шахматами и поэтессами

Работа на пару человеколет.

WebSocket + Binary JSON

Но всё равно придётся делать свои XEP'ы.

Есть вещи которые по стандарту верны, но могут не работать

Например?

Твой мессенджер поддерживает XMPP если у него нет проблем с самыми популярными серверами (аля openfire).

Хех, ну логично, а на чем ещё проверять? :)

для некоторых вещей аля пересылка файлов есть ворох несовместимых rfc

Стандарт де-факто - SI. Другое дело, что работает он этак в 10% случаев.

Ну и сама концепция городить обмен xml ну просто эпический фейл

Ну а какие ещё варианты? Бинарный протокол что ли?

Как раз в тему, вчера попробовали с товарищем по pidgin'у через жаббер поговорить - работает сносно. (раньше пункт в меню voice call был не активен).

меня интересует вопрос, попутно, как там с шифрованием обстоят дела.

Ну а какие ещё варианты? Бинарный протокол что ли?

Ну я выше написал.

Это только один из способов передачи файлов в XMPP (base64), есть ещё два... один напрямую (не работает через NAT), и второй через proxy, вроде со вторым проблем нет?..

Писал сервер xmpp — протокол полная хрень на двух гигантских rfc

Так может стоит придумать что-то поновее XMPP?

В целом, спасибо за пост, похоже, это и есть полный ответ на мой вопрос.

Ну можно голые бинарные данные по сокетам гнать. Главное должен быть какой-то СТАНДАРТ. Я ничего нового сейчас не предлагаю, просто хочу понять проблемы того, что УЖЕ есть.

Какой-то стандарт у нас уже есть %)

Так может стоит придумать что-то поновее XMPP?

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

Пишу для яббера ботов и серверные транспорты. На мой взгляд фундаментальный недостаток только один - идиотский вид передаваемых данных.

XML абсолютно бредовый и нечитабельный. Пример:

<query xmlns='http://jabber.org/protocol/disco#info'/> <!-- запрос на получение списка сервисов -->
<query xmlns='http://jabber.org/protocol/disco#items'/> <!-- запрос на получение списка элементов одного сервиса -->

А вот ещё примерчик:

<error type='cancel' code='400'>
  <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>

Короче говоря, по читабельности такой протокол немногим отличается от бинарного. Тогда возникает вопрос - а нафига тогда вообще было делать его на основе XML?

Как было сказано выше, огромные rfc не располагают разработчика к детальному изучению протокола. Русской информации по протоколу почти нет. А ведь нужно учитывать, что жаббер это не только c2s но и межмодульное взаимодействие. http://post.hppi.troitsk.ru/~mike/XMPP/jabberd2-scheme.png На этой схеме модули соединены линией. Эта линия - соединение данные по которому передаются по протоколу xmpp. Инфы по межмодульному взаимодействию почти нет даже на английском. Только документация.

Но само устройство протокола мне нравится. Много возможностей для расширения. Был бы он читабельный да дока попроще и можно бы было назвать его гениальным изобретением.

Про ненужность xml говорили?

// Не читал, да

Так может стоит придумать что-то поновее XMPP?

http://about.psyc.eu/

Очевидно же! Отказываются, потому что втулить рекламу в свой, банально огороженный, протокол проще, чем спамить через XMPP. Во-вторых, если не заметил, таким образом тебя заставляют(!) сидеть на сайте(!).

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

запилил вой Hangouts вместо-то google talk и работает это уже не через xmpp

Обана, а я думал, что они тупо название поменяли.

Объективный недостаток только один — отсутствие огороженности.

Всё остальное озвученное в теме — не более, чем лёгкие неудобства, решаемые как одноразово на уровне библиотек, так и в перспективе развитием протокола. Но такая открытость, увы, современным монстрам не нужна.

Например?

XML-неймспейсы.

На хабре похожая тема была.

Так может стоит придумать что-то поновее XMPP?

Надо найти очень много единомышленников, сделать рабочее решение клиента и сервера под разные платформы, написать гейты в другие популярные протоколы, внести многие фишки типа аудиозвонков и видеоконференций, активно пеариться и, может быть, повезёт. Работы на годы.

А иначе это будет ещё один мёртвый стандарт.

Что он умеет?

http://about.psyc.eu/Category:Feature

Например?

Делаешь ответ по rfc3921, а pidgin его не понимает.

Ну а какие ещё варианты? Бинарный протокол что ли?

В принципе, тут даже не так важно представление и объём как

1) нормальное разбитие на пакеты, а не «абстрактный поток данных» который ты сам сидишь как обезьянка и считаешь кол-во открывающих и закрывающих скобочек чтобы отделить друг от друга несколько ответов и скармливать их xml-парсеру.

2) упростить протокол до вменяемого кол-ва состояний и чтобы описание работы не занимало OVER 200 СТРАНИЦ RFC.

Короче, возвращаясь к твоему вопросу, хоть json, хоть yaml будет лучше. Всё что угодно лучше xml потому что тупо для элементарного обмена информацией тянется весь тяжёлый xml с кучей наворотов. Причём, местами не совместимый с самим xml (в неймспейсах, что порождает проблемы с использованием уже готовх xml-либ аля ElementTree). Да что там, самого понятия «xml-поток» тупо нет. Большинство либ не могут напрямую парсить то что прилетает по жабберу. Им нужны все заголовки включая «<?xml version=„1.0“ encoding=„UTF-8“ ?>».

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

PS я ламер в xml и мог наговорить глупостей. Я знаю это.

Делать внутри протокола команды ссылками которые 100 лет невалидны - я даже не знаю какую траву курил разработчик протокола.

man XML namespace. По ссылке и не должно быть ничего. А когда у некоторых форматов там было что-то автоматические обработчики нехило нагружали серваки, постоянно их вытягивая оттуда.

Давай напишем свой RFC?

Большинство либ не могут напрямую парсить то что прилетает по жабберу. Им нужны все заголовки включая «<?xml version=„1.0” encoding=„UTF-8” ?>».

Это какие-то очень странные либы, ведь эта штука в XML не обязательна. Правда дефолтная кодировка не везде принимается UTF-8 (по стандарту там что-то другое, AFAIR).

Какие фундаментальные проблемы у XMPP

Зумель.

Давай напишем свой RFC?

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

Если хочется just for fun то вполне можно кинуть клич в Development и там наверняка подскажут верные решения. Я бы единственное что посоветовал это начать с диаграммы состояний протокола и уже её разворачивать в сам протокол. Причём, достаточно условно обозначить типа «клиент послал hello и пароль в шифрованном виде» -> «server сказал connection established». Можно даже, в случае авторизации, сразу данные слать, нафига клиенту получать подтверждение что авотризация прошла? Достаточно слать уведомление в случае если она не прошла.

Потом подумать над представлением этих данных (json, например, его все кроме меня любят). И затем подумать в каком виде передавать.

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

Всё вышесказанное моё скромное имхо.

Это какие-то очень странные либы

Хм, странно, я щас проверил, питоновский ElementTree нормально парсит куски либ. Ну что ж, спишем на мою молодость, это было лет 7-8 назад.

Щас выяснится что я просто криворукий лох не осиливший стандарты...

1) нормальное разбитие на пакеты, а не «абстрактный поток данных» который ты сам сидишь как обезьянка и считаешь кол-во открывающих и закрывающих скобочек чтобы отделить друг от друга несколько ответов и скармливать их xml-парсеру.
Да что там, самого понятия «xml-поток» тупо нет. Большинство либ не могут напрямую парсить то что прилетает по жабберу. Им нужны все заголовки включая «<?xml version=„1.0” encoding=„UTF-8” ?>».

Имхо, это проблема либ, а не протокола. Нормальные либы (в тч питон-обертка над ElementTree, наверняка сама ElementTree тоже) умеют кушать поток.

Замена xml на json/yaml ничего не меняет по сути. На n лишних символов на единицу данных всем в наше время наплевать, я думаю.

Почему от него начинают отказываться? Google, потом втентаклик. Изобретают свой велосипед? Чем XMPP плох?

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

А то, что от в итоге пострадают 1.5 гика, которые зачем-то использовали неродные клиенты для подключения к gmail или, еще хуже, S2S, никому дела нет.

Иксмеэл убивает всё.

Иксмеэл убивает всё.

А так же мозги тех, кто его использует.

Замена xml на json/yaml ничего не меняет по сути.

+inf

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

у нас из-за этой особенности xml, ПО не завелось на 5 из сотни серверов, в итоге разрабы потратили неделю и в конце сунули всю схему в xml файл, т.к. парсила его стороняя либа

с тех пор с XML у меня любовь 8)

Стандарт не имеет приличных средств для NAT Traversal. Как следствие, для конечного пользователя не важно, что там за номера XEP, важно то, что видео и аудио работает через раз. А этого уже достаточно, чтобы видео и аудио в рамках XMPP не пользоваться. Вторая проблема того же свойства — кодеки, реализованные в разных клиентах, трудносовместимы между собой.

Поэтому Hangouts, который гонит трафик через промежуточные сервера Гугла, имеет стандартизированный кодек имени Гугла, умеет работать как с клиентом, так и без, да к тому же имеет весьма пристойную реализацию видеоконференций, а главное — вебинаров, т.к. позволяет без проблем подключать дикое количество пользователей к просмотру — это логичное решение задачи.

Это понятно. Не понятно почему просто не расширили его рекламным блоком и слали бы рекламу спокойно в клиенты (надо бы было просто пробашлять разрабам qip чтобы они добавили показ её) и все бы были довольны. Хомички бы смотрели рекламу, я бы продолжал пользоваться втентаклем и гуглем...

Не понятно почему просто не расширили его рекламным блоком

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