Комментарии 211
Чтобы сказать, что протокол устарел — он должен перестать выполнять свои функции в полной мере, поддержка его должна стать слишком дорогой или передаваемые им порции данных начать выглядеть полным трешем и требовать применения телепатии для их интерпретации (камень в сторону SMTP).
Ничего подобного не наблюдается. Чего-то не хватает? Напишите свой XEP (английскими буквами, если что), либо поищите среди готовых.
Ничего подобного не наблюдается. Чего-то не хватает? Напишите свой XEP (английскими буквами, если что), либо поищите среди готовых.
Чтобы объявить протокол устаревшим, должна существовать достойная замена. Пока такого не наблюдается.
Напишите свой XEP (английскими буквами, если что), либо поищите среди готовых.
Написать можно, но есть ли хоть какая-то уверенность, что его начнут поддерживать мессенджеры? Если собственный протокол вк либо реализуют более или менее внятно, либо не реализуют вообще, то в случае с XMPP получится что-то вида «ну, у нас же есть XMPP, как-то работает, а то, что не работает — это ВК слишком умный», и будет не совсем понятный user experience. КМК, это довольно распространенный подход среди изготовителей чего угодно — пусть лучше у нас будет меньше пользователей, но у них будет работать заведомо так, как мы хотим, чем больше, но у которых это будет работать как-то непонятно как (тот же Apple тому примером).
Если у вас есть свой клиент, использующий xmpp — вы вполне можете реализовать в нём любой нужный вам XEP. Пример — гугловский Jingle
В любом случае, я не знаю о чём-то таком, что использовал VK и что не укладывалось в базовый набор XEP'ов протокола. С другой стороны VK я вообще не использую, как, прочем, и любую другую соцсеть. Могу чего-то не знать.
В любом случае, я не знаю о чём-то таком, что использовал VK и что не укладывалось в базовый набор XEP'ов протокола. С другой стороны VK я вообще не использую, как, прочем, и любую другую соцсеть. Могу чего-то не знать.
Скорее всего действительно все укладывалось. Но во-первых, у ВК есть свой API, который в любом случае поддерживать нужно, тк на нем завязано вообще все (я подозреваю, что и веб-версия тоже). А во-вторых, я подозреваю, что в каждом клиенте есть персональные баги, а недовольный пользователь условного ткаббер, который такой вообще один, поднимет шумихи столько, что покажется, что этот XMPP не работает у 10%, и либо обвинения в том что «аа, у вас плохая позиция», либо в том, что «аа, вы криворукие идиоты», и, похоже, компании уверенно идут по первому пути (Гугл тому примером). Подход же с заточенностью XMPP под конкретный клиент — он логичный, если нет своего API, но он есть, и самые популярные XMPP-клиенты его поддерживают в любом случае, то есть XMPP нужен для экзотики, среди которой непонятно как выделить что-то внятное.
Не очень удачный пример про Jingle. Объективно, GTalk мёртв, а других стабильных (или хотя бы готовых к использованию неэнтузиастами) реалзиаций на основе libjingle я например не знаю.
Хотя конечно, очень хотелось бы поиметь свободную альтернативу скайпу.
Хотя конечно, очень хотелось бы поиметь свободную альтернативу скайпу.
GTalk мёртв стараниями Google. Так же как многое из его старых продуктов… Но Jingle, при этом, поддерживается десятком сторонних клиентов.
Десятком? А можно список?
Нормальную, юзабельную поддержку я (вчера искал) нашёл только в Jitsi.
Плагин миранды так и не был допилен.
Pidgin не умеет его на windows.
Psi+ пока не проверял, но 11 месяцев с последнего стабильного релиза это многовато. И вроде бы оно не умеет видео.
Нормальную, юзабельную поддержку я (вчера искал) нашёл только в Jitsi.
Плагин миранды так и не был допилен.
Pidgin не умеет его на windows.
Psi+ пока не проверял, но 11 месяцев с последнего стабильного релиза это многовато. И вроде бы оно не умеет видео.
десятком сторонних клиентов.
Нормальную, юзабельную поддержку
Давайте не выходить за рамки. Астериск по-вашему клиент? Или может FreeSWITCH?
Или вы просто увидели список и думаете что каждый из них готов к использованию?
Номинальная поддержка не означает что этим можно пользоваться. По факту имеем два с половиной клиента, и то не на всех платформах.
Если заявляется поддержка протокола, он должен поддерживаться.
Как минимум в talkonaut она работала нормально. По крайней мере эксперимент удался. В Psi Jungle так же работает.
Не вижу смысла проверять весь список, который поддерживается в актуальном состоянии сообществом.
> десятком сторонних клиентов.
Клиентов там 15 штук
Как минимум в talkonaut она работала нормально. По крайней мере эксперимент удался. В Psi Jungle так же работает.
Не вижу смысла проверять весь список, который поддерживается в актуальном состоянии сообществом.
> десятком сторонних клиентов.
Клиентов там 15 штук
как минимум — если кто-то посылал музыку — другие клиенты просто _вообще_ ничего не видели(ладно — понятно что не предлагали mp3 скачать — но даже сообщение что тут что-то было — не было).
А как оно выглядело в самом вконтакте?
Как сообщение. Нажав на него, песня начинала играть в плеере.
Песня нажимает?
Пользователь нажимает, а песня начинает играть в плеере.
Вообще, как вариант, слать headline-сообщение с урлом, который при открытии в браузере запустит мелодию
headline
headline — The message is probably generated by an automated service that delivers or broadcasts content (news, sports, market information, RSS feeds, etc.). No reply to the message is expected, and a compliant client SHOULD present the message in an interface that appropriately differentiates the message from standalone messages, chat sessions, or groupchat sessions (e.g., by not providing the recipient with the ability to reply).
Надеялся, моё замечание по поводу некорректного построения фразы с точки зрения русского языка будет понятно
А как это работает в клиентах на API вконтакта?
XEP-0066: Out of Band Data позволяет прислать пользователю сообщение, к которому прикреплена музыка/кино/фотка/whatever. Дальше клиент своими средствами это проигрывает/показывает в чатике. Все придумано за вас :)
Смайлики, приватные фотографии не прикладывались к сообщению. Точнее, клиент ничего не говорил и не показывал — игнорировал такое сообщение. Но это корявая реализация со стороны vk.com: в вебе фотографии, по-моему, ссылкой показывались, не понятно почему они не присылали такую же в jabber.
НЛО прилетело и опубликовало эту надпись здесь
Никак. Протокол основан на XML и это его базовое свойство. Это может быть недостатком (имхо, не фатальным), но порции данных всё равно не велики. Что такое 500 байт по сравнению с 0.5 мегабайта тела современной веб-страницы? На данный момент эта проблема не актуальна, имхо. Ну или если очень хочется — есть gzip, применяемый для сжатия текстовых данных.
Там не то, проблемы не в размере пакета данных, а как часто он запрашивается/рассылается, в частности пакет проверки статуса online клиента может занимать до 40% всего трафика в сети jabber.
Эта проблема не была особо принципиальной даже во времена дорогого GPRS/EDGE и J2ME клиента Bombus на телефоне) А сейчас в век быстрого и безлимитного 3G совсем не актуально)
Перевести в JSON?
Весьма странная тенденция, от xmpp отказались qip, google talk, vk. Неужто сделать свой протокол с нуля легче чем помочь сообществу допилить их?
У xmpp есть фатальный недостаток
Какой?
Имелось в виду это.
Это цитата из описания эволюции windows:
i72.narod.ru/humor/revolution.htm
--
Ох и долго же я коммент писал :)
i72.narod.ru/humor/revolution.htm
--
Ох и долго же я коммент писал :)
qip? Разве?
Как заставить сообщество включить показ рекламы?
А когда Google Talk отказался от XMPP?
habrahabr.ru/post/180159/ вот тут подробнее. Гугл развивает hangouts, xmpp пока поддерживается, но не факт что не прикроют, как они это умеют.
Когда запустил Hangouts как замену Google Talk для Android.
есть одна объективная причина: ВК не хочет поддерживать протокол, через который сидит минимальное количество людей, т.к. у них есть свой api, который например поддерживается qip'ом, самый популярным мессенджером.
C QIP
есть проблемы
И не только эти, с ним вообще непойми что происходит.
к сожалению озвучка не относится к преимуществам протокола. Ее можно прикрутитьк чему угодно, было бы желание.
Она не относится к преимуществом протокола, но поддерживающих XMPP программ намного больше, и к некоторым из них озвучка уже прикручена.
верно, но например в обсуждении отключения XMPP на роеме (ссылка выше), про озвучку не сказано ни слова, что показывает необходимость этой фичи в сообществе.
Конечно, это именно так. Но сила стандарта — в разнообразии, по большому счету. Кому-то нужна озвучка, кому-то — заковыристое шифрование, кому-то — что-то еще, итд. Штука как раз в том, что если есть ein protokoll, ein client, то получается, что разработчик клиента должен думать обо _всех_ этих мелочах, а если протокол стандартный, то условное общество слепых может тихо пилить свой форк какого-нибудь pidgin, в котором соответствующая штука будет реализована, и не заботиться об условном шифровании.
НЛО прилетело и опубликовало эту надпись здесь
И тут есть одна объективная причина: ВК не захочет поддерживать незрячих, которых минимальное количество, т.к. у них есть свой api, сайт, QIP, планы завоевания мира и куча других вещей, которые приносят бабла побольше, чем люди, не видящие баннеров. Не захочет, если даже узнает
А пока они даже не замечают, что у них есть незрячие пользователи и что они как-то могли их сетью пользоваться.
<span class='moral'>Забота об инвалидах — это признак развитого и цивилизованного общества, лакмусовая бумажка, которая показывает, всё ли на самом деле так хорошо, как написано в промо-тексте на главной странице.</span>
А пока они даже не замечают, что у них есть незрячие пользователи и что они как-то могли их сетью пользоваться.
<span class='moral'>Забота об инвалидах — это признак развитого и цивилизованного общества, лакмусовая бумажка, которая показывает, всё ли на самом деле так хорошо, как написано в промо-тексте на главной странице.</span>
дорогой мой, вы прочитайте комменты выше. Ни XMPP поддерживала озвучку, а озвучку прикрутили. С готовой реализацией на xmpp, у вас уйдет пара вечеров для написания плагина для qip с озвучкой. Постарайтесь ради гуманизма.
stetzen всё прекрасно написал: у сообщества есть программы с поддержкой XMPP, адаптированные для незрячих. Вконтакт их отключил, и вы предлагаете писать новые под API Вконтакта или QIP.
Почему нет пункта «Дуров, убейся об стену»?
> Протокол действительно(объективно) устарел?
> свой вариант в комментариях
Как-то так вышло, что *всё* общение у меня прходит в skype, у меня по прежнему открыт gajim на третьем рабочем столе, но мне никто не пишет и я никому не пишу.
> свой вариант в комментариях
Как-то так вышло, что *всё* общение у меня прходит в skype, у меня по прежнему открыт gajim на третьем рабочем столе, но мне никто не пишет и я никому не пишу.
С протоколом все нормально, с доходами контакта что-то не так, поэтому протокол «объективно» признали не пригодным.
Устарел — не устарел, но там без S2S от него толку было действительно мало.
А как на другие серверы приходили бы сообщения, со вложенными «Аудиозаписями», «Видеозаписями», «постами» и анимированными смайлами из VK?
Раньше приходил какой-то стринг, наподобие bbcode. Теперь просто режется.
Я думаю, они пожалели ресурсов по-хорошему оформлять всё в ХЕРы, больно уж много кастомных вещей пришлось бы документировать.
Раньше приходил какой-то стринг, наподобие bbcode. Теперь просто режется.
Я думаю, они пожалели ресурсов по-хорошему оформлять всё в ХЕРы, больно уж много кастомных вещей пришлось бы документировать.
Ссылками? А смайлики транслировать в текстовые (все, надеюсь, знают как в том же QIP'е реализованы анимированные смайлики?).
Есть же уже XEP, который позволяет прикреплять к сообщению все это.
НЛО прилетело и опубликовало эту надпись здесь
Ммм… Странный вопрос: а что такое push-сообщения в контексте VK? Я онным не пользуюсь, но возможно знаю ответ о существовании/несуществовании такой сущности в xmpp
Современные мобильные клиенты не должны держать свои соединения ни с какими серверами в фоне. Вместо они должны использовать инструменты iOS/Android. XMPP так не может. Следовательно, расход батареи и траффика возрастает и нафиг этот XMPP никому не нужен.
> не должны держать свои соединения ни с какими серверами в фоне
Как вы себе это представляете? Напоминаю, у клиента нет белого IP, чтобы сервер мог постучаться ему сам.
И открытое соединение не значит, что по нему передаются данные в данный конкретный момент — это логическое состояние.
Как вы себе это представляете? Напоминаю, у клиента нет белого IP, чтобы сервер мог постучаться ему сам.
И открытое соединение не значит, что по нему передаются данные в данный конкретный момент — это логическое состояние.
> Вместо они должны использовать инструменты iOS/Android. XMPP так не может
В XMPP есть транспорты практически в любую IM сеть. В чём принципиальная невозможность использовать тот же фокус, чтобы пробрасывать станзы через iOS/Android push технологию клиенту, который её понимает?
В XMPP есть транспорты практически в любую IM сеть. В чём принципиальная невозможность использовать тот же фокус, чтобы пробрасывать станзы через iOS/Android push технологию клиенту, который её понимает?
А вы про push-уведомления или push/pull технологию?
Свой вариант.
Тут скорее вопрос применения, а не устаревания. Главная и самая большая проблема протокола — избыточность. Он хорош тогда, когда нужна простота работы с протоколом, но только на стабильных каналах.
Был такой j2me IM клиент — jimm, и я прекрасно помню, как jabber тупил и вываливался в оффлайн при нестабильном gprs соединении, когда бинарный icq вполне себе работал. Кроме того, jabber серьёзно выжирал трафик в отличии от icq. Так, что я в принципе понимаю почему они отказались от его использования в пользу собственного протокола, но мне не нравится такая поспешность. Я бы оставил для совместимости.
Для кастомных же проектов — xmpp на данный момент незаменим.
Тут скорее вопрос применения, а не устаревания. Главная и самая большая проблема протокола — избыточность. Он хорош тогда, когда нужна простота работы с протоколом, но только на стабильных каналах.
Был такой j2me IM клиент — jimm, и я прекрасно помню, как jabber тупил и вываливался в оффлайн при нестабильном gprs соединении, когда бинарный icq вполне себе работал. Кроме того, jabber серьёзно выжирал трафик в отличии от icq. Так, что я в принципе понимаю почему они отказались от его использования в пользу собственного протокола, но мне не нравится такая поспешность. Я бы оставил для совместимости.
Для кастомных же проектов — xmpp на данный момент незаменим.
JIMM разве поддерживал XMPP? Он вроде был только для OSCAR.
Для XMPP был отличный мобильный клиент Bombus, и падений особых не было и трафик выжирался не критично даже для дорогого в то время GPRS. Несколько лет на нем просидел и был полностью доволен этим месенджером.
Зато после удобных Jabber конференций, Skype конференции кажутся убогими.
Для XMPP был отличный мобильный клиент Bombus, и падений особых не было и трафик выжирался не критично даже для дорогого в то время GPRS. Несколько лет на нем просидел и был полностью доволен этим месенджером.
Зато после удобных Jabber конференций, Skype конференции кажутся убогими.
Зато после удобных Jabber конференций, Skype конференции кажутся убогими.Абсолютно согласен, но вот всё равно — после запуска собственного jabber сервера, даже в веб-клиентом без регистрации есть человек 10, которые упорно сидят в старом skype чате
Помню так-же было с ICQ, когда некоторые мои знакомые упорно продолжали в нем сидеть) Вопрос решился написанием «транспорта»(по сути обычный бот) позволявшего сидеть через ICQ в jabber-конференциях… в итоге все попробовавшие это знакомые перелезли на jabber с ICQ. А вот с приходом быстрого интернета и Skype, пошел быстрый отток пользователей из jabber'а туда и, увы, уже без возврата обратно.
Таки-был джаббер, его вкрутили первоначально в Jimm Multi (российский форк), потом он постепенно разошёлся по остальным дистрибуциям. Код основан значительной частью на костях Бомбуса.
Хо-хо, да вы OSCAR не видели. По-моему XMPP со своим XML не страдает такой избыточностью, как сам OSCAR. Там матрёшка в матрёшке, завёрнутая в свой формат сериализации и посыпанная сверху URL-энкодингом. Настолько всё неоптимально, что я ужаснулся, когда столкнулся с этим протоколом.
Таки видел) И даже участвовал в разработке одной из библиотек для работы с ним) Приколов там хватало, начиная с постоянной смены пары-тройки байт при авторизации клиента и заканчивая работой этого «бинарного» протокола безо всяких попыток его пожать)
А вас не напрягало использование XML внутри бинарных данных, запакованных внутри других бинарных данных?) В частности так устроены XTraz'ы (через которые шлются x-статусы).
А обмен XTraz'ами с сервером, насколько я помню, происходил всегда по запросу со стороны клиента и никакой важной информации кроме обновления x-стаусов в ростере не нес, поэтому этот функционал можно было тупо не реализовывать, как мы и поступили) Вообще мне кажется, что XML был использован только потому, что фичу с X-статусами в ICQ внедряли с кем-то наперегонки и поэтому ваяли как получится, особо не заморачиваясь на красоте протокола.
Причём Bombus умудрялся восстанавливать подключение после проезда между станций метро, а Jimm падал и только перезапуск помогал.
В Jimm для Jabber, насколько я помню, не было сжатия, в отличии от того же Bombus'а, поэтому он ел на порядок больше траффика и имел следующие из этого факта проблемы. В современном мире Jabber есть траффика не больше, чем такие бинарные протоколы, как ICQ/OSCAR.
У меня была обратная ситуация, там где Jimm не работал, там работал Jabber. А благодаря сжатию трафика тратилось в 10-20 раз меньше. XML очень хорошо жмется. В итоге Jimm жрал в 10 раз больше трафика и был нестабильнее.
Сидеть в ICQ через Jabber было куда дешевле и без потерь соединений.
Сидеть в ICQ через Jabber было куда дешевле и без потерь соединений.
Одна из серьёзных проблем XMPP — использование XML, который достаточно накладно парсить и достаточно накладно представлять в памяти. Мы с другом (по большей части он) писали свой XMPP-сервер — и я помню, как мой друг матерился на то, что XMPP использует XML. XML удобен для чтения человеком, но вовсе не «удобен» для машины. Бинарный протокол мог бы требовать на порядок меньших накладных расходов. А XMPP построен скорее теоретиками, нежели практиками.
Другая проблема XMPP, которая, правда, вряд ли могла оказать влияние на отказ вконтакта от XMPP, — это чрезмерное изобилие всяких XEP-ов, которыми стандарт основательно раздут. Для практически любой задачи существует множество решений. Закладки на MUC и сайты можно хранить как в Private Storage, так и на pubsub; для распространённой технологии vCard существует альтернатива в виде XEP-0154, которую так и приняли; способов же передачи файлов вообще уйма.
Ноги у этой проблемы растут из того факта, что XEP-ы пилятся сообществом и часто недостаточно согласованно, то есть не учитывая друг друга, а это не есть хорошо. Конечно, XMPP Council должны отвечать за такие проблемы, но, как мы можем видеть, фактически никто ни за что не отвечает.
С другой стороны, я всё-таки думаю, что считать протокол устаревшим — это как минимум странно. Об устаревании той или иной вещи говорят тогда, когда есть лучшая альтернатива. Где эта альтернатива?
Другая проблема XMPP, которая, правда, вряд ли могла оказать влияние на отказ вконтакта от XMPP, — это чрезмерное изобилие всяких XEP-ов, которыми стандарт основательно раздут. Для практически любой задачи существует множество решений. Закладки на MUC и сайты можно хранить как в Private Storage, так и на pubsub; для распространённой технологии vCard существует альтернатива в виде XEP-0154, которую так и приняли; способов же передачи файлов вообще уйма.
Ноги у этой проблемы растут из того факта, что XEP-ы пилятся сообществом и часто недостаточно согласованно, то есть не учитывая друг друга, а это не есть хорошо. Конечно, XMPP Council должны отвечать за такие проблемы, но, как мы можем видеть, фактически никто ни за что не отвечает.
С другой стороны, я всё-таки думаю, что считать протокол устаревшим — это как минимум странно. Об устаревании той или иной вещи говорят тогда, когда есть лучшая альтернатива. Где эта альтернатива?
А ведь когда-то давно автор qip'а хотел сделать бинарный формат на замену xmpp. Тогда его помню закидали смешками и прочими предметами.
Неудивительно — ведь узнаёт о таких сообществах обычно только сообщество IT-шников, а им такая новость вряд ли будет в радость, потому что они уже привыкли к одному, хорошо умеют с ним работать, у них есть куча готовых реализаций этого протокола. А тут им что-то новое предлагают, которое ещё и не факт, что станет стандартом RFC. В конце концов, одна из целей существования XMPP — унификация, то есть, этот протокол стремится стать единым стандартом для IM, как стал тот же HTTP для веба.
Имхо, XEP'ы — как раз плюс. Благодаря им мы имеем одинаково рабочую реализацию базового функционала во всех клиента и серверах. А механизм информирования о поддерживаемых расширениях протокола позволяет избегать проблем с совместимостью клиентов.
На ум приходят только проблемы с передачей файлов, которые чаще всего проистекают из неверной конфигурации сервера, да самодейтельность QIP'а, который пытался впихнуть тег <smile/> для смайлов в конференциях. Всё бы хорошо, только они за каким-то хреном эскейпили последовательность символов и другие клиенты воспринимали тег как текст (коим он по стандарту xml и являлся).
На ум приходят только проблемы с передачей файлов, которые чаще всего проистекают из неверной конфигурации сервера, да самодейтельность QIP'а, который пытался впихнуть тег <smile/> для смайлов в конференциях. Всё бы хорошо, только они за каким-то хреном эскейпили последовательность символов и другие клиенты воспринимали тег как текст (коим он по стандарту xml и являлся).
> которые чаще всего проистекают из неверной конфигурации сервера
Не соглашусь. Уж если передавать файлы через сервер, то методом in-band работать будет всегда, гарантированно, независимо от настроек сервера, но вообще это очень плохая идея использовать сервер для передачи данных, даже если речь о прокси. Скорее, вся беда в том, что IPv6 развивается слишком медленно, иначе бы давно у всех были белые IP и необходимость в любых костылях отпала бы сама собой, а заодно сразу заработали бы нормально всяческие Jingle.
Не соглашусь. Уж если передавать файлы через сервер, то методом in-band работать будет всегда, гарантированно, независимо от настроек сервера, но вообще это очень плохая идея использовать сервер для передачи данных, даже если речь о прокси. Скорее, вся беда в том, что IPv6 развивается слишком медленно, иначе бы давно у всех были белые IP и необходимость в любых костылях отпала бы сама собой, а заодно сразу заработали бы нормально всяческие Jingle.
Я имел ввиду XEP-0065. Там при неверной конфигурации или стараниями файрвола проблемы с соединением регулярно возникают. Но да, слать большие объёмы данных по XEP-0047 — идея плохая.
Кстати, вот что меня сейчас озадачило: для передачи данных peer to peer нужен белый ip у отправляющего. Но если белый адрес есть у принимающего, но нет у отправляющего? Технически установить соединение для передачи данных возможно, но XMPP не умеет.
Кстати, вот что меня сейчас озадачило: для передачи данных peer to peer нужен белый ip у отправляющего. Но если белый адрес есть у принимающего, но нет у отправляющего? Технически установить соединение для передачи данных возможно, но XMPP не умеет.
Скорее, вся беда в том, что IPv6 развивается слишком медленно, иначе бы давно у всех были белые IP и необходимость в любых костылях отпала бы сама собой
Некоторые сознательно садятся за нат.
Я уверен, что гораздо больше людей за NAT оказались не по своей воле.
В принципе вы правы, конечно, но тут вопрос в том что считать «своей» волей. Является ли желание начальника «своей» волей или нет?
В конце-концов если бы не было желающих сидеть за NAT'ом, то вряд ли бы он появился в IPv6, так ведь?
А он — тут как тут: tools.ietf.org/html/rfc6296
В конце-концов если бы не было желающих сидеть за NAT'ом, то вряд ли бы он появился в IPv6, так ведь?
А он — тут как тут: tools.ietf.org/html/rfc6296
Плюс ещё у многих есть возможность получить белый айпшник, но они её игнорируют, поскольку это им обойдется баксов в 5 месяц. Это своя воля или нет?
К сожалению большинство домашних «хомячков» и знать не знает чем отличается «белый» IP от «серого».
А так же не имеет хоть каких-то знаний о том, почему стоит использовать или открытое или лицензионное п/о, и зачем нужны антивирусы (а, их надо покупать?, а зачем, я лучше крякну) и обновления на операционную систему, жаву и флеш с броузером (меня и мой ie6/mozilla 3.6 вполне устраивает) — именно по этому и получается, что проще NATить, закрывать samba/smtp порты с точки зрения безопасности чтобы пиратская непатченная винда не обменивалась троянами с соседями и не рассылала спам.
(ответы типичных хомячков реальные кейсы в техподдержку). Имено по этмоу многие вендоры стараются хоть как-то нести ИТ грамотность в массу.
ну и вторая сторона — на всех IPшниками не напасёшься -жаба-жаба, в случае некоторых больших broadband операторов в СНГ,
И доп «условия» вроде «не держать дома сервера».
Ну и тарифные политики…
А так же не имеет хоть каких-то знаний о том, почему стоит использовать или открытое или лицензионное п/о, и зачем нужны антивирусы (а, их надо покупать?, а зачем, я лучше крякну) и обновления на операционную систему, жаву и флеш с броузером (меня и мой ie6/mozilla 3.6 вполне устраивает) — именно по этому и получается, что проще NATить, закрывать samba/smtp порты с точки зрения безопасности чтобы пиратская непатченная винда не обменивалась троянами с соседями и не рассылала спам.
(ответы типичных хомячков реальные кейсы в техподдержку). Имено по этмоу многие вендоры стараются хоть как-то нести ИТ грамотность в массу.
ну и вторая сторона — на всех IPшниками не напасёшься -жаба-жаба, в случае некоторых больших broadband операторов в СНГ,
И доп «условия» вроде «не держать дома сервера».
Ну и тарифные политики…
Насчёт удобства чтения XML человеком вы немного поторопились. Скажем так, удобнее — да, удобен — врядли.
Вот про YAML можно сказать что он удобен с меньшей натяжкой.
Вот про YAML можно сказать что он удобен с меньшей натяжкой.
А что в XML неудобного? В нём даже в тех же закрывающих тегах явная избыточность, предусмотренная как раз во имя удобства чтения. Вон, допустим, тег закрывается как
</foo>. Что мешает закрыть его просто </>? В стеке ведь всё равно есть имя текущего элемента. Нет же, имя дублируется — чтобы читающий видел, что именно закрылось.
XML удобен для чтения человеком, но вовсе не «удобен» для машины
Тут могу сказать только ЛОЛ ШТО?. XML был придуман как формализованный формат данных для обмена между машинами. Но так-как людям тоже хотелось читать его сделали еще и человеко-читаемым. Я не знаю что у вашего друга вызвало такие проблемы. Видимо он не почитал что такое xml и какие методы парсинга для него существуют. И видимо пытался сделать свой парсер. Из-за этого и все проблемы.
Он использовал expat
Весьма странно, так-как он вполне себе удобен. Так что маты могут быть вызваны исключительно не пониманием сути XML.
Этот человек работал с XML достаточно много и вообще он весьма опытный программист и хороший математик. Вообще как вы можете судить о человеке, не пообщавшись с ним? Его негодование вызвано не неудобствами работы с XML, а тем, какие структуры данных приходилось организовывать в памяти.
По вашему рассказу у меня сложилось именно такое впечатление :)
А вот это уже вопрос того что сделали в самом XMPP и к XML как понимаете имеет отдаленное отношение. Можно конвертнуть в бинарное представление XMPP и получим ровно те же структуры.
а тем, какие структуры данных приходилось организовывать в памяти.
А вот это уже вопрос того что сделали в самом XMPP и к XML как понимаете имеет отдаленное отношение. Можно конвертнуть в бинарное представление XMPP и получим ровно те же структуры.
Формализованный не значит удобный для парсинга. XML удобно парсить, когда нужно загрузить документ целиком в память один раз и работать с ним неоднократно. Когда из многосотмегабайтного документа нужно выбрать лишь несколько нод по определенному критерию, то загружать весь документ несколько накладно.
Эм вообще говоря для описанного случая придуман SAX. У XML есть два разных метода работы с ним. Первый это постройка всего дерева в память это DOM и второй потоковый это SAX как раз когда у нас файлы большого размера.
Назвать SAX удобным у меня язык не поворачивается.
Для указанных целей вполне. Если вам внезапно надо потом развернуть дерево длинное, то это уже отдельный шиза.
Хотелось бы иметь инструмент типа регулярок, но учитывающий специфику XML. Собственно регулярки оказались лучшим инструментом, но XML к ним приходилось готовить специально — вырезать все незначащие пробелы, а значащие менять на единый, исключать комментарии и т. п., иначе даже монструозные регэкспы не справлялись.
Многие Jabber библиотеки пишутся с использованием XPath, где документом является каждая отдельно пришедная станза с сервера, все отлично работает и парсится.
Регулярки работают не быстрее DOM-парсера и xpath-запросов. Не говоря уже о том, что идея применения регулярок для xml пахнет ересью )
XML не регулярный язык, а КС. Так что регуляркам нет пути. Есть XPath.
А если для этого использовать всякие XQuery и XPath?
> Одна из серьёзных проблем XMPP — использование XML, который достаточно накладно парсить и достаточно накладно представлять в памяти.
Что вы говорите :) XML, как один из более-менее читаемых языков, очень сильно вытягивал на заре, когда все только пилили клиенты. Множество проблем можно было решить, просто открыв XML консоль в клиенте.
Да, даже не на заре. Буквально 3 недели назад ресёчил проблему на jabber сервере, опять же через консоль (не работало добавление в ростер. пиджин и ejabberd). А копипаст нескольких «цитат» из потока в гугл + ключевые слова подсказали ответ.
Возможно, XMPP выжил и выстрелил именно потому, что в стандарте приведены читаемые примеры протокола, а не таблички со смещениями и битами, которые только своим видом обещают гемор разработчику, а также потому, что любую реализацию можно сравнить с примером из XEPа за 2 секунды и без hex-редактора.
Что вы говорите :) XML, как один из более-менее читаемых языков, очень сильно вытягивал на заре, когда все только пилили клиенты. Множество проблем можно было решить, просто открыв XML консоль в клиенте.
Да, даже не на заре. Буквально 3 недели назад ресёчил проблему на jabber сервере, опять же через консоль (не работало добавление в ростер. пиджин и ejabberd). А копипаст нескольких «цитат» из потока в гугл + ключевые слова подсказали ответ.
Возможно, XMPP выжил и выстрелил именно потому, что в стандарте приведены читаемые примеры протокола, а не таблички со смещениями и битами, которые только своим видом обещают гемор разработчику, а также потому, что любую реализацию можно сравнить с примером из XEPа за 2 секунды и без hex-редактора.
Сначала кто-то увидел в консоли вот это:
и испугался. Потом рассказал знакомому, xmpp шлёт много трафика. И всё. Теперь об этом знает любой, кто слишал название XMPP, но проверять, актуальна ли проблема, и проблема ли вообще это — не модно.
<message from="xxx@xxx" type="chat" xml:lang="ru" to="yyy@yyy" id="aae6a">
<body>test</body>
<active xmlns="http://jabber.org/protocol/chatstates"/>
<request xmlns="urn:xmpp:receipts"/>
</message>
и испугался. Потом рассказал знакомому, xmpp шлёт много трафика. И всё. Теперь об этом знает любой, кто слишал название XMPP, но проверять, актуальна ли проблема, и проблема ли вообще это — не модно.
Это хорошо во время разработки и для разработчиков, но плохо в релизе. А вечная разработка это ужас.
Для общения в социальной сети базового xmpp-протокола уже недостаточно.
Придумать сотню новых ХЕР-ов Вконтакт может.
А вот заставить реализовать эти ХЕР-ы в 100500 клиентах — это вряд ли.
Тут проще собрать в свою секту… ой! под своим API новую паству…
Тем более что API уже есть
А еще у Макаревича помните «Не стоит прогибаться под изменчивый мир — Пусть лучше он прогнется под нас»
Придумать сотню новых ХЕР-ов Вконтакт может.
А вот заставить реализовать эти ХЕР-ы в 100500 клиентах — это вряд ли.
Тут проще собрать в свою секту… ой! под своим API новую паству…
Тем более что API уже есть
А еще у Макаревича помните «Не стоит прогибаться под изменчивый мир — Пусть лучше он прогнется под нас»
Но ведь никто, собственно, и не просит новые фичи представлять именно в виде XEP-ов. Они могли бы выпустить собственный мессенджер, в котором это было бы реализовано, а уж потом задуматься о том, чтобы предложить свои нововведения сообществу в качестве новых стандартов.
Вообще не вижу смысла гадать о причинах отказа; было бы куда интереснее, если бы свой комментарий оставил представитель вконтакта, в котором доходчиво изложил, почему XMPP объективно устарел.
Вообще не вижу смысла гадать о причинах отказа; было бы куда интереснее, если бы свой комментарий оставил представитель вконтакта, в котором доходчиво изложил, почему XMPP объективно устарел.
А он устарел не объективно.
Он плохо согласуется с возможностями социальной сети ВК. То есть устарел субъективно (только не надо тыкать мне ответ службы поддержки — у них типичные отмазки).
Я не очень хорошо знаю возможности вконтакт-АПИ и практически не общаюсь в соц-сетях, но как по-вашему с помощью jabber-клиента «лайкнуть твит» или просто залить «фоточку на стену»?
Условно говоря — двигатель внутреннего сгорания объективно не устарел. Но если вы хотите не ездить по земле, а построить самолет или ракету — надо делать качественные изменения, а не пытаться мелкими изменениями добиться результата.
Он плохо согласуется с возможностями социальной сети ВК. То есть устарел субъективно (только не надо тыкать мне ответ службы поддержки — у них типичные отмазки).
Я не очень хорошо знаю возможности вконтакт-АПИ и практически не общаюсь в соц-сетях, но как по-вашему с помощью jabber-клиента «лайкнуть твит» или просто залить «фоточку на стену»?
Условно говоря — двигатель внутреннего сгорания объективно не устарел. Но если вы хотите не ездить по земле, а построить самолет или ракету — надо делать качественные изменения, а не пытаться мелкими изменениями добиться результата.
Мне вообще кажется, что вся эта шумиха вокруг якобы устаревания XMPP и деградации свободной сети Jabber связана лишь с тем, что протокол и сеть просто перешли в фазу зрелости. Критики ссылаются на то, что году в 2004-2006 писалось несоизмеримо больше ботов, транспортов, клиентов и серверов, чем сейчас, а в комнатах было больше народа. Сейчас былой активности нет, но это вполне закономерно: боты, сервера, клиенты и транспорты уже давно написаны, а сеть (Jabber) окончательно покинули те, кто просто «пробовал» её для себя.
Кривая зрелости
Кривая зрелости
> но как по-вашему с помощью jabber-клиента «лайкнуть твит» или просто залить «фоточку на стену»?
Шутите? В XMPP протокол это добавляется на раз два через XEP-ы. Туда можно легко добавить и стену и даже просмотр видеороликов (сам поток конечно будет через http). А в своём XMPP клиенте можно сделать абсолютно любой фронтенд на эти функции, даже неотличимый от самого вконтакте.
Было бы желание
Шутите? В XMPP протокол это добавляется на раз два через XEP-ы. Туда можно легко добавить и стену и даже просмотр видеороликов (сам поток конечно будет через http). А в своём XMPP клиенте можно сделать абсолютно любой фронтенд на эти функции, даже неотличимый от самого вконтакте.
Было бы желание
Я смутно догадываюсь (и написал об этом выше) что придумать новый XEP вовсе не сложно.
И даже не очень сложно на своем собственном сервере этот ХЕР реализовать.
А дальше встает проблема как заставить авторов жаббер-клиентов *это* поддержать, если *это* реализовано только у ВК
Причем *это* оказывается либо неприменимым для других жаббер-серверов, либо в случае реализации другими серверами *это* на другом сервере может оказаться конкурирующим с ВК
Я не рассуждаю — правильное или неправильное решение принял ВК.
Я размышляю о причинах этого. А время покажет — было ли решение верным.
И даже не очень сложно на своем собственном сервере этот ХЕР реализовать.
А дальше встает проблема как заставить авторов жаббер-клиентов *это* поддержать, если *это* реализовано только у ВК
Причем *это* оказывается либо неприменимым для других жаббер-серверов, либо в случае реализации другими серверами *это* на другом сервере может оказаться конкурирующим с ВК
Я не рассуждаю — правильное или неправильное решение принял ВК.
Я размышляю о причинах этого. А время покажет — было ли решение верным.
Если нет желания у ВК допиливать остальные клиенты, никто этого и не просит.
Достаточно:
— опубликовать XEP-ы, если вообще есть интерес в сторонних реализациях.
— всем остальным клиентам, кто не поддерживает фичу (это легко определить) отправлять «здесь должна быть картинка из ВК, но ваш клиент её не поддерживает, используйте наш клиент (ссылка)».
Достаточно:
— опубликовать XEP-ы, если вообще есть интерес в сторонних реализациях.
— всем остальным клиентам, кто не поддерживает фичу (это легко определить) отправлять «здесь должна быть картинка из ВК, но ваш клиент её не поддерживает, используйте наш клиент (ссылка)».
Т.е. раз они не смогли заставить реализовать эти ХЕР-ы 100500 разработчиков, то смогут заставить их реализовать их новый API? Вряд ли :)
А если им плевать на остальные клиенты и достаточно полноценного своего, то что мешает всем, кто не поддерживает эти XEP-ы (а это легко определить, есть функция для этого), отправлять что-то типа «здесь должна быть картинка, но ваш клиент не поддерживает её, используйте наш клиент».
NIH синдром у них там.
А если им плевать на остальные клиенты и достаточно полноценного своего, то что мешает всем, кто не поддерживает эти XEP-ы (а это легко определить, есть функция для этого), отправлять что-то типа «здесь должна быть картинка, но ваш клиент не поддерживает её, используйте наш клиент».
NIH синдром у них там.
Непонятно только, как в этом XMPP делать групповые разговоры, чтобы было как в VK. Есть комнаты, но это по-моему не совсем то.
В XMPP есть XEP для динамического создания конференций путем получения их из приватного диалога, либо путем создания новой. Плюс к этому можно приглашать в нее пользователей. Другой вопрос, что мало какие клиенты это умеют делать.
На момент написания этого комментария еще не решил, вы ругаетесь, или мне гуглить новый термин.
Т.е. это по сути те же комнаты, только создаются на лету? И можно поподробнее, что за XEP?
«XEP-0307: Unique Room Names for Multi-User Chat» позволяет сгенерировать уникальное имя конференции, но, к сожалению, статус «отложен до лучших времен» из-за отсутствий реализаций. В реальной жизни вполне обходится генерацией уникального UUID.
XEP-0045: Multi-User Chat: Continue описывает процесс превращения приватного диалога в конференцию с сохранением контекста.
XEP-0045: Multi-User Chat: Continue описывает процесс превращения приватного диалога в конференцию с сохранением контекста.
Понятно. В принципе, слепив это вместе можно попробовать получить что-то похожее.
Мне кажется, слабая поддержка вот такого создания групповых разговоров на лету и является одной из основных причин отказа от XMPP.
Мне кажется, слабая поддержка вот такого создания групповых разговоров на лету и является одной из основных причин отказа от XMPP.
Я не совсем вас понимаю. Как будто сейчас групповые разговоры создаются не на лету? Для того, чтобы создать комнату, достаточно сформировать presence на её JID, указав свой ник в качестве ресурса. Инициировав несколько таких presense самим сервером, вы автоматически создадите комнату и автоматически запишете в неё группу участников. Другое дело, что уведомить программу-клиент об этом на данном этапе развития XMPP не получится. А вот в веб-интерфейс интегрировать это не было бы проблемой.
Если это не поддерживается клиентами и будет работать только на вебе, зачем вообще использовать XMPP?
А зачем вводить новый протокол с нуля, который вообще ещё пока ни у кого не реализован? :) Не накладнее ли это, чем допилить совсем немного?
На мой взгляд, причин использовать XMPP две.
1. Он уже разработан, можно брать и использовать.
2. Поддерживается многими клиентами.
Но если возможностей не хватает и мы начинаем его допиливать, то эти преимущества почти пропадают: текущие клиенты использовать это не смогут, и протокол надо дорабатывать. Чем это лучше разработки своего протокола?
1. Он уже разработан, можно брать и использовать.
2. Поддерживается многими клиентами.
Но если возможностей не хватает и мы начинаем его допиливать, то эти преимущества почти пропадают: текущие клиенты использовать это не смогут, и протокол надо дорабатывать. Чем это лучше разработки своего протокола?
Видел я один раз это нечто под названием «групповые разговоры» Вконтакте и в связи с этим возникает вопрос: зачем нужны эти косые групповые разговоры, когда есть удобные jabber-конференции?
Что с этими групповыми разговорами не так?
Лучше они тем, что когда надо организовать групповой разговор, достаточно сделать пару кликов и можно общаться. Ну, я имею в виду с теми, кто есть в вк. А для использования jabber-конференций надо для начала объяснить людям, что такое jabber и зачем оно им вообще надо.
Лучше они тем, что когда надо организовать групповой разговор, достаточно сделать пару кликов и можно общаться. Ну, я имею в виду с теми, кто есть в вк. А для использования jabber-конференций надо для начала объяснить людям, что такое jabber и зачем оно им вообще надо.
Я надеюсь, вы понимаете, что сказали чушь?
Пара кликов — это лишь тонкость реализации, никак не зависящая от протокола, лежащего в основе. Вообще никак!
Пара кликов — это лишь тонкость реализации, никак не зависящая от протокола, лежащего в основе. Вообще никак!
Ну по большому счету тут дело именно не в протоколе(по большому счету тот-же IRC справился бы в роли чата для ВК ничем не хуже, чем XMPP), а в особенностях реализации. Вконтакте групповые чаты, по моему мнению, слепили на коленке только для того, чтобы было — вообще никак не задумываясь о юзабельности.
Это у вас пониманием что-то. Специально же написал:
Речь была не про особенности реализации, а про то, что для общения с людьми, которые зарегистрированы в вк, воспользоваться родными средствами гораздо проще, чем пытаться затащить людей в какую-то jabber-конференцию. Для начала, им надо объяснить, что это вообще такое, этот jabber, что им надо ставить и почему мы не можем пообщаться просто в вк без всего этого геморроя.
Собственно, мой пост никак не противоречит вашему утверждению:
Ну, я имею в виду с теми, кто есть в вк.
Речь была не про особенности реализации, а про то, что для общения с людьми, которые зарегистрированы в вк, воспользоваться родными средствами гораздо проще, чем пытаться затащить людей в какую-то jabber-конференцию. Для начала, им надо объяснить, что это вообще такое, этот jabber, что им надо ставить и почему мы не можем пообщаться просто в вк без всего этого геморроя.
Собственно, мой пост никак не противоречит вашему утверждению:
Пара кликов — это лишь тонкость реализации, никак не зависящая от протокола, лежащего в основе. Вообще никак!
А что если бы контакт создал «родное средство», но работающее по XMPP? Пришлось бы тогда что-то объяснять?
Думаю, что для пользователя, который с Jabber не знаком и пользовался только веб-клиентом, все равно да. Но в принципе, ему и не надо, ведь вопрос в том, что если продвинутый пользователь захочет воспользоваться своим любимым XMPP-клиентом, то он сможет (если клиент поддерживает все используемые фичи).
Главный минус — убогий интерфейс. Ну и я там не нашел банального таргетированного сообщения. Когда в чате сидит 10+ человек, будет очень геморно определять кому пришло сообщение. По удобству это нечто еще хуже, чем в свое время были ICQ чаты.
Ну до некоторого времени, насколько я понимаю, в ВК был свой jabber-сервер, т.ч. объяснять было не особо сложно — сразу с примерами.
Ну до некоторого времени, насколько я понимаю, в ВК был свой jabber-сервер, т.ч. объяснять было не особо сложно — сразу с примерами.
Это да. А вот если бы в основе этих групповых разговоров лежали те же XMPP-конференции, каждый мог бы выбирать сам, как в них общаться — через «двухкликовый» веб-интерфейс, просто создающий комнату и прописывающий в ней участников, или же использовать любую программу, умеющую XMPP и MUC…
Ну вот и причина, почему XMPP не использовался) Для ВК все-таки в приоритете, чтобы пользователи общались именно через вэб-интерфейс, или на крайний случай через мобильный клиент который показывает рекламу. А XMPP позволил бы полностью абстрагироваться от сайта ВК и его рекламы, при этом используя его базу пользователей.
Кстати и в XMPP пара кликов — есть приглашения
Угу. Только у этого Телеграма есть фатальный недостаток, он повторяет судьбу G+ — зашел туда, а там никого!
Если они добавлять туда всех из вконтакте — скрестят с вконтактовской перепиской, то все будет ок.
Это было бы куда более странно, чем отказаться от XMPP.
Как же тогда они собираются обрабатывать и отсылать сообщения из ВК на телефон? Всем к своим аккаунтам привязать телефоны?
Просто получается, если они это сделают — приложение станет аддоном, чтобы пользователь из ВК мог общаться с пользователем не из ВК, и + основная группа общения не меняется.
А вот если бы они скрестились бы с FB… =)
Как же тогда они собираются обрабатывать и отсылать сообщения из ВК на телефон? Всем к своим аккаунтам привязать телефоны?
Просто получается, если они это сделают — приложение станет аддоном, чтобы пользователь из ВК мог общаться с пользователем не из ВК, и + основная группа общения не меняется.
А вот если бы они скрестились бы с FB… =)
Меня вот интересует, сколько из полутора тысяч человек проголосовавших знает внутренности xmpp достаточно хорошо, чтобы оценить, устарел он или нет?
Думаю, больше, чем было бы, если бы вопрос был не об XMPP, а о другом протоколе :)
Меня вот заинтересовало, а насколько девелоперы контакта знакомы с существующим положением дел, заявляя подобное? Объективно ли в принципе «устарение» для использования, когда сам протокол развивается и поддерживается?
Что должно быть в потрохах протокола или в окружающей среде, чтобы сказать «устарел»?
Что должно быть в потрохах протокола или в окружающей среде, чтобы сказать «устарел»?
Устаревает протокол когда он уже не поспевает за современными достижениями, например как те же POP3 и SMTP которые до сих пор используют 7-битную кодировку и для современной почты уже нужны костыли чтобы их использовать(одних только способов указать кодировку письма и передавать двоичные данные — целый ворох). Вот протокол IMAP — он уже более современный, хотя менее популярный(хотя он ближе к мессенджерам).
Когда-то писал клиент и rss-бота, так что беру на себя смелость сказать «да» )
Только не rss-бот, а rss-транспорт, для сервера OpenFire. Исправить не успел.
Гм, у меня талант отвечать не в попад. В общем, как минимум один из полутора тысяч знает )
Можете объяснить как и в чем именно он устарел? Про XML уже говорили, может есть еще существенные недостатки которых ксепами не исправить?
del
XMPP может и не нов и не идеален, но он живее всех живых, и у нас продолжает свою жизнь в Chat SDK — уже сотни мобильных приложений есть (iOS, Android, Windows Phone, BlackBerry), которые сделали чат на основе QuickBlox SDK, в котором, в том числе, применяется XMPP.
Недавно для одних клиентов провели лоад-тестинг на 180 тыс одновременных чат подключений, при грамотной настройке работает отлично.
Недавно для одних клиентов провели лоад-тестинг на 180 тыс одновременных чат подключений, при грамотной настройке работает отлично.
Вообще наблюдаю тенденцию ухода от XML в сторону JSON/BSON. Можно вспомнить тот же Qt c их переходом от QML к QtQuick.
Лично по моему опыту — это потому, что web-разработчики ленится изучать xml и инструменты для работы с ним, считая его чем-то монструозным. Когда я говорю, что мне предпочтительнее получать XML, так как его проще интерпретировать в данные — я вижу квадратные глаза.
QtQuick — это стандартная библиотека компонентов для QML, если что :)
Но тенденция перехода от XML к JS-подобным вещам там присутствует.
Но тенденция перехода от XML к JS-подобным вещам там присутствует.
Я достаточно хорошо разбираюсь в IM-протоколах — реализовывал бинарный ICQ-протокол, реверс-инженерил Skype, реализовывал клиентов, ботов, серверные сервисы XMPP, и даже писал свой сервер в порядке эксперимента, писал клиента нового вконтактового MTProto. Хоть меня уже слили однажды за такое мнение, но повторюсь — XMPP нельзя называть устаревшим, но он не реализовывает и не может реализовать множество возможностей, которые требуются от современных IM-протоколов, и XEP-ами эта проблема не решается — они располагаются на слишком высоком уровне.
А именно:
1. Стабильная работа на нестабильном сетевом соединение — если соединение рвётся, сообщения могут теряться, как входящие, так и исходящие. XMPP работает исключительно по TCP и полагается на стабильность соединения, нет возможности создавать сессии, размазанные по нескольким соединениям, нет гарантированной доставки сообщений, существует XEP-0184, но он до сих пор Draft и никем не поддерживается и не решает проблемы полностью, так как находится на высоком уровне и распространяется далеко не на все сообщения протокола.
2. Нет возможности доставки сообщений на все девайсы пользователя и синхронизации истории между ними — с доставкой gtalk решил проблему, нарушив спецификацию XMPP, но это ему не очень помогло.
3. Нет возможностей отправки медиавложений в сообщения — фотографии, видео, геолокоейшоны и прочее. Даже если реализовать поверх костылями, это будет работать не очень хорошо и с большим оверхедом.
4. Нет единого стандарта на отправку файлов, существует огромное количество разнообразных костылей и proxy service для этого.
5. MUC для организации групповых чатов слишком неудобен и его очень непросто интегрировать с существующими сервисами, как в случае ВК, не верите — почитайте спецификацию, почитайте ВК-апи, и попробуйте предположить, как могла бы работать подобная интеграция, не нарушая спецификаций XMPP.
6. Ещё можно добавить, что сам протокол тяжел, гибок не в том месте, где надо и избыточен, но это уже много раз обсуждалось и сущие мелочи по сравнению с недостатками выше.
А именно:
1. Стабильная работа на нестабильном сетевом соединение — если соединение рвётся, сообщения могут теряться, как входящие, так и исходящие. XMPP работает исключительно по TCP и полагается на стабильность соединения, нет возможности создавать сессии, размазанные по нескольким соединениям, нет гарантированной доставки сообщений, существует XEP-0184, но он до сих пор Draft и никем не поддерживается и не решает проблемы полностью, так как находится на высоком уровне и распространяется далеко не на все сообщения протокола.
2. Нет возможности доставки сообщений на все девайсы пользователя и синхронизации истории между ними — с доставкой gtalk решил проблему, нарушив спецификацию XMPP, но это ему не очень помогло.
3. Нет возможностей отправки медиавложений в сообщения — фотографии, видео, геолокоейшоны и прочее. Даже если реализовать поверх костылями, это будет работать не очень хорошо и с большим оверхедом.
4. Нет единого стандарта на отправку файлов, существует огромное количество разнообразных костылей и proxy service для этого.
5. MUC для организации групповых чатов слишком неудобен и его очень непросто интегрировать с существующими сервисами, как в случае ВК, не верите — почитайте спецификацию, почитайте ВК-апи, и попробуйте предположить, как могла бы работать подобная интеграция, не нарушая спецификаций XMPP.
6. Ещё можно добавить, что сам протокол тяжел, гибок не в том месте, где надо и избыточен, но это уже много раз обсуждалось и сущие мелочи по сравнению с недостатками выше.
Если говорить короче, проблема XMPP в том что у него или много путей решения одной проблемы или ни одного из-за этого сделать на нем функционально богатый и корректно работающую IM сеть или сложно или же надо прибивать гвоздями один клиент и воротить так как удобно. Это в свое время сделал google.
Явного дублирования там нет, часть XEP'ов помечена как устаревшие, и им на замену рекомендованы другие, часть, как с передачей файлов — не дублируют друг друга, а дополняют.
Вы можете реализовать только In-Band, по принципу «лишь бы было», и сэкономить время до релиза приложения, а завершить полноценную реализацию уже потом. И это будет работать со всеми существующими клиентами.
Расширения протокола позволяют его делать модульным, позволяя реализовывать только то, что реально нужно. И это… красиво )
Вы можете реализовать только In-Band, по принципу «лишь бы было», и сэкономить время до релиза приложения, а завершить полноценную реализацию уже потом. И это будет работать со всеми существующими клиентами.
Расширения протокола позволяют его делать модульным, позволяя реализовывать только то, что реально нужно. И это… красиво )
1) Я сталкивался с этой проблемой, но она была разрешена ещё пока я использовал xmpp — реализовали уведомления о доставке/недоставке, если оба пользователя в сети. Потерь сообщений при сохранении их на сервере я не наблюдал.
2) Есть, через команды управления. Как в других клиентах не знаю, но psi/psi+ его реализовывал. А на гугл как раз ругались за то, что он реализовал синхронизацию не по спецификации.
3) Большие оверхеды XMPP — да, множество раз упомянутая проблема. В большинстве случаев остаётся надеяться на gzip,
4) Стандарты есть, 3 XEP'а: In-Band (передача через протокол в base64 кодировке, используется как крайняя мера), SOCKS5 proxy, используется если не удаётся установить p2p соединение и, собственно, p2p. И их 3 штуки потому, что это 3 разные сущности, описывающие поведение в разных ситуациях. Соответственно клиенты их стараются применить в порядке p2p->SOCKS5->In-Band
5) Подробно не разбирался с конференциями, ничего сказать не могу.
6) Про объём данных — как уже писал выше, gzip. Но вообще да, когда в xml появляется пара нэймспейсов, он начинает выглядеть… многословно.
2) Есть, через команды управления. Как в других клиентах не знаю, но psi/psi+ его реализовывал. А на гугл как раз ругались за то, что он реализовал синхронизацию не по спецификации.
3) Большие оверхеды XMPP — да, множество раз упомянутая проблема. В большинстве случаев остаётся надеяться на gzip,
4) Стандарты есть, 3 XEP'а: In-Band (передача через протокол в base64 кодировке, используется как крайняя мера), SOCKS5 proxy, используется если не удаётся установить p2p соединение и, собственно, p2p. И их 3 штуки потому, что это 3 разные сущности, описывающие поведение в разных ситуациях. Соответственно клиенты их стараются применить в порядке p2p->SOCKS5->In-Band
5) Подробно не разбирался с конференциями, ничего сказать не могу.
6) Про объём данных — как уже писал выше, gzip. Но вообще да, когда в xml появляется пара нэймспейсов, он начинает выглядеть… многословно.
1. Не вижу проблемы. Любой клиент должен ждать, что какой-то пакет не дойдёт и соединение разорвётся в любой момент. Если этого нет — то бага клиента. Если что-то должно дойти гарантировано, значит надо подтверждить сообщением о доставке.
В конце-концов, что мешает сделать XEP на XMPP сессию размазанную по нескольким TCP сессиям? Достаточно договориться с сервером в самом начале о таймауте и каком-нить ID сессии, а потом когда TCP сессия оборвётся и восстановится, послать этот ID и сервер загрузит только то, что не было доставлено. Пока таймаут не истёчет ни сервер ни клиент не завершают XMPP сессию. Если включен такой режим, то клиент и сервер могут дополнительно подтверждать каждую станцу специальным сообщением о доставке.
2. У каждого клиента есть приоритет. И если у двух клиентов одинаковый приоритет, то сообщения получают оба. Так было, несколько лет назад. И на историю на сервере тоже был XEP.
3. По-моему всё это было уже давно. Лет 5 назад на ткаббере был плагин, который показывал собеседников на карте земли, т.е. геолокация уж точно была. Да и файлы можно было пересылать. Или я не совсем понимаю о чём речь.
4. Уже ответили на это, но зацепило вот это «огромное количество разнообразных костылей». Это вы XEP-ы называете костылями, или речь о чём то другом?
5. МУК — это чаты как в IRC. Именно для этого создавался этот стандарт. Чаты, как в ВК, сделаны по другому, и естественно, что МУК будет не удобен для них. Это как копать молотком, и жаловаться, что не удобно. Если молоток не подходит, возьмите лопату, т.е. сделайте другой XEP.
6. «гибок не в том месте» — это где он гибок, где не надо? «избыточен» — а это где?
В конце-концов, что мешает сделать XEP на XMPP сессию размазанную по нескольким TCP сессиям? Достаточно договориться с сервером в самом начале о таймауте и каком-нить ID сессии, а потом когда TCP сессия оборвётся и восстановится, послать этот ID и сервер загрузит только то, что не было доставлено. Пока таймаут не истёчет ни сервер ни клиент не завершают XMPP сессию. Если включен такой режим, то клиент и сервер могут дополнительно подтверждать каждую станцу специальным сообщением о доставке.
2. У каждого клиента есть приоритет. И если у двух клиентов одинаковый приоритет, то сообщения получают оба. Так было, несколько лет назад. И на историю на сервере тоже был XEP.
3. По-моему всё это было уже давно. Лет 5 назад на ткаббере был плагин, который показывал собеседников на карте земли, т.е. геолокация уж точно была. Да и файлы можно было пересылать. Или я не совсем понимаю о чём речь.
4. Уже ответили на это, но зацепило вот это «огромное количество разнообразных костылей». Это вы XEP-ы называете костылями, или речь о чём то другом?
5. МУК — это чаты как в IRC. Именно для этого создавался этот стандарт. Чаты, как в ВК, сделаны по другому, и естественно, что МУК будет не удобен для них. Это как копать молотком, и жаловаться, что не удобно. Если молоток не подходит, возьмите лопату, т.е. сделайте другой XEP.
6. «гибок не в том месте» — это где он гибок, где не надо? «избыточен» — а это где?
2.
Доставка сообщений на все подключенные клиенты (чтобы при перескакивании с устройства на устройство история не дробилась): XEP-0280: Message Carbons (имеет реализации на серверах и клиентах)
Синхронизация истории с сервером: XEP-0313: Message Archive Management (на данный момент реализован только на одном сервере).
Доставка сообщений на все подключенные клиенты (чтобы при перескакивании с устройства на устройство история не дробилась): XEP-0280: Message Carbons (имеет реализации на серверах и клиентах)
Синхронизация истории с сервером: XEP-0313: Message Archive Management (на данный момент реализован только на одном сервере).
Добавьте сюда видео- и аудиочаты, которые не могут работать на TCP, да ещё в XML-сериализации.
Jingle предусматривает реализацию VoIP поверх UDP, так что для передачи аудио/видео TCP не используется нигде, кроме самой инициализации соединения.
у нас работают, вот пример с исходником для iOS, XMPP используется для handshake, а данные через TCP, NAT traversal решается с помощью STUN сервера
Странно, никто не упомянул SIP.
Это же Агент техподдержки написал. Он, ЕМНИП, вообще не сотрудник вконтакта. И может писать что вздумается.
Дуров, верни рейтинг!
Ответ Прост: ВК продвигают свой велосипед, тек же, как Гугли продвигают свой.
Я являюсь разработчиком IM сервиса в своем проекте (проект имеет 25-30К одновременно открытых сессий).
Мы решили отказаться от XMPP в сторону более простого JSON для мобильных клиентов, и простой REST для всего остального.
Мы решили отказаться от XMPP в сторону более простого JSON для мобильных клиентов, и простой REST для всего остального.
Протокол, конечно, не устарел и едва ли устареет в ближайшие годы.
Но вот его реализация на практике удручает.
Пытался найти связку из сервера, клиента для Android и клиента для Windows, чтобы синхронизировалась история. Фигушки! XEP-0313: Message Archive Management не поддерживает ни один клиент и только один сервер. Расширению XEP-0136: Message Archiving уже много лет (оно уже даже третий год как deprecated), но до спарку Android+Windows мне настроить не удалось.
В общем, протокол-то хороший, а толку шиш.
Но вот его реализация на практике удручает.
Пытался найти связку из сервера, клиента для Android и клиента для Windows, чтобы синхронизировалась история. Фигушки! XEP-0313: Message Archive Management не поддерживает ни один клиент и только один сервер. Расширению XEP-0136: Message Archiving уже много лет (оно уже даже третий год как deprecated), но до спарку Android+Windows мне настроить не удалось.
В общем, протокол-то хороший, а толку шиш.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Устарел ли протокол XMPP?