Comments 31
UFO just landed and posted this here
На счет 201, это конечно таки да, но потом, код — который разгребает презенс сообщения, выглядит просто ужасно: наличие тех или иных элементов\кодов в станзе, может означать очень большое количество вещей, для каждой из которых нужна отдельная логика. То есть с моей точки зрения, логичней было бы — много ивентов, и много хендлеров, а сейчас один параметризированный ивент, да еще и таким образом, что логики почти нет, просто надо знать.
А где это он в Lync используется? Там же SIP.
SIP используется для установки аудио\видео звонков. XMPP возможно для обмена сообщениями, и точно для федерейшн. Пруф
Судя по описанию вы взяли готовый протокол и готовую реализацию. При небольшой доработке получили устроивший вас результат и решили поставленную задачу. И попытались приравнять к недостаткам то что вам пришлось вносить некоторые доработки и читать документацию. Серьезно? Вы считаете это недостатком? А чем тогда должны заниматься разработчики, решая задачу написания сервиса по обмену сообщениями? Брать опенсорсный протокол и его опенсорсную реализацию, прикручивать нескучный интерфейс и, не внося никаких существенных изенений, сдавать заказчику? Как-то оно это… Не совсем честно, имхо.
Суть статьи, в том, что мы не уверены, что написание собственного протокола и собственной реализации, заняла бы больше времени и нервов, чем взять готовый «опенсорсный» протокол, и его реализацию и начать ею пользоваться. К реализации ХМРР в инкарнации Prosody как сервера у нас ни одной претензии нет, кроме одной махонькой, с которой согласились сами разработчики. К протоколу у нас есть некоторые замечания, или если он «опенсорсный», то типа нельзя говорить, что вот это и то, по моему мнению, сделано не так как бы хотелось? Почему я не могу этим делиться? С моей точки зрения ХМРР немного отстал от текущего положения вещей, особенно, меня печалит 0045. Что не честного в размышлении о таких вещах?
Да не, то что вы предлагаете идеи по улучшению протокола — это прекрасно. Надеюсь что вы донесете свою мысль до разработчиков.
Это развитие, это хорошо.
моя мысль заключалась в том что брать опенсорсный протокол с опенсорсной реализацией и жаловаться на то что пришлось допиливать напильником и тратить на это время… Ну это не совсем честно. Опенсорс по умолчанию подразумевает что есть некая экспертиза, выраженная в коде, и которую любой желающий может использовать свободно в своих целях. Это изначально конструктор. И каких-то блоков может не оказаться, придется их делать самому. Но это совершенно не сопоставимо с разработкой и изготовлением всех блоков самостоятельно.
Это развитие, это хорошо.
моя мысль заключалась в том что брать опенсорсный протокол с опенсорсной реализацией и жаловаться на то что пришлось допиливать напильником и тратить на это время… Ну это не совсем честно. Опенсорс по умолчанию подразумевает что есть некая экспертиза, выраженная в коде, и которую любой желающий может использовать свободно в своих целях. Это изначально конструктор. И каких-то блоков может не оказаться, придется их делать самому. Но это совершенно не сопоставимо с разработкой и изготовлением всех блоков самостоятельно.
моя мысль заключалась в том что брать опенсорсный протокол с опенсорсной реализацией и жаловаться на то что пришлось допиливать напильником и тратить на это время…
Проблема в том, что, возможно, лучший опенсорс-протокол для обмена сообщениями не отвечает современным реалиям. А это не то, что от него ожидаешь.
Будте спокойны. Написание собственного протокола и реализация заняла бы больше времени (тогда заняла бы). Когда что-то уже есть, то проще начать это использовать и быстро выявить недостатки/неприминимость в своем системном окружении. Когда нет ничего, нужно еще на практике наловить кучу своих граблей, наловить кучу «особенностей реализации» других систем. И это пожиратели времени суммируются и кодингом, проектированием…
XMPP со своими плюсами и минусами есть и некоторое время еще будет. И пока ни кто не спешит написать ему полноценную замену.
XMPP со своими плюсами и минусами есть и некоторое время еще будет. И пока ни кто не спешит написать ему полноценную замену.
UFO just landed and posted this here
Я 3 (три) раза пытался использовать XMPP, оно даже доходило до продакшна, но в итоге всё равно приходилось переделывать на что-то другое, заточенное под конкретные нужды.
Во вторых, получение истории — это указание от какой даты хочешь и какой лимит. Как по мне, так пейджинг был бы здесь уместнее.Еще в прошлой статье удивился, но не отписал так как не читал XEP.
Это сделано намерено — в промежутке между получениями страниц могут появиться новые сообщения и пейджинг бы возвращал дубликаты, а если историю догрузили спустя 30 минут и 100 сообщеий, то пришлось бы загружать несколько страниц состоящих только из дубликатов или считать входящие.
При первом взаимодействии с контактом (вы открыли чата с ним, или он написал вам сообщение), посылаем запрос на получение N последних сообщений, теперь у нас есть коллекция, в которой есть N или N+1 сообщений или пустой ответ, в этом случае ничего не надо делать. Теперь, как только это произошло, и ответ не был пустым — посылаем запрос на пейджинейдет историю, и как параметр запроса указываем дату самого первого(earliest) сообщения, что у нас уже есть. Ответ кешируем. Теперь можно пользоваться пейджингом без проблем и не будет никаких дубликатов. Конечно, если у вас нет машины времени. То есть в моем варианте — мы берем точку отсчета: Самое раннее сообщение, которое есть на клиенте, и продолжаем с шагом назад. В случае реализации ХМРР, нам нужно указать дату в прошлом и от нее с шагом вперед. Пейджинг, он и тут есть из коробки, только не в ту сторону: Result Set Management (XEP-0059).
запрос N1
запрос N2
И, я так понимаю, запрос N3
Против того, что, если я правильно понял берем текущую дату и получаем N сообщений, берем дату самого старого и получаетм ещё N и так далее. Все одним и тем же запросом.
Ну и я как-то не понял, как в вашей схеме обходится то, что описал DnAp: пока мы получали страницу с номером N нам написали ещё 2 cообщения, и 2 последних сообщения со страницы N перешли на страницу N+1?
посылаем запрос на получение N последних сообщений
запрос N2
посылаем запрос на пейджинейдет историю, и как параметр запроса указываем дату самого первого(earliest) сообщения
И, я так понимаю, запрос N3
Теперь можно пользоваться пейджингом без проблем
Против того, что, если я правильно понял берем текущую дату и получаем N сообщений, берем дату самого старого и получаетм ещё N и так далее. Все одним и тем же запросом.
Ну и я как-то не понял, как в вашей схеме обходится то, что описал DnAp: пока мы получали страницу с номером N нам написали ещё 2 cообщения, и 2 последних сообщения со страницы N перешли на страницу N+1?
Абсолютно сумасшедшая мысль. Что если хранить историю сообщений локально в SQLite и сортировать по времени?
Можно потом формировать вывод как угодно.
Можно потом формировать вывод как угодно.
вопрос в получении истории от сервиса, синхронизации между девайсами и т.д. Вывод все ещё можно формировать как угодно
На сколько я понял проблему, в данном случае у нас будут дубликаты сообщений. В случае с SQLite это решается парой запросов.
По поводу синхронизации между девайсами — лучше pgp и торрентов пока не могу придумать. можно передавать Magnet ссылку средствами самого протокола. Но даже если ее перехватят, страшного ничего в этом нет. Ломать pgp то еще удовольствие.
Не люблю описывать словами свои идеи. Лучше, конечно, схему рисовать. но это надо углубляться и смотреть ваш код.
По поводу синхронизации между девайсами — лучше pgp и торрентов пока не могу придумать. можно передавать Magnet ссылку средствами самого протокола. Но даже если ее перехватят, страшного ничего в этом нет. Ломать pgp то еще удовольствие.
Не люблю описывать словами свои идеи. Лучше, конечно, схему рисовать. но это надо углубляться и смотреть ваш код.
На сколько я понял проблему, в данном случае у нас будут дубликаты сообщений.
как напишешь, так и будет.
По поводу синхронизации между девайсами — лучше pgp и торрентов пока не могу придумать
просто хранить переписку на сервере, не? и после переустановки приложения она никуда не пропадёт
просто хранить переписку на сервере, не? и после переустановки приложения она никуда не пропадёт
Но кто на это согласится, господа? (с) Ржевский.
Идея синхронизации между устройствами понятна. У меня есть история сообщений на всех устройствах и если одно выходит из строя — это не критично, сообщения подтянутся потом после восстановления. Вероятность отказа всех устройств одновременно примерно равна вероятности отказа хранилища в датацентре.
Облачную услугу хорошо бы монетизировать. Кому надо — подпишутся на хранение защищенной копии своих сообщений на удаленном сервере. На условиях что закрытый ключ есть только у пользователя и расшифровать может только он. Но это подойдет не всем. Многие принципиально не будут отдавать свою переписку. Даже в зашифрованном виде.
Вероятность отказа всех устройств одновременно примерно равна вероятности отказа хранилища в датацентре.
Нет, она равна вероятности отказа одного устройства, поделённое на количество устройств. И если количество равно единице…
Когда пишут свой чат, наиболее вероятная ситуация, что это происходит для корпоративных нужд, так что многие просто идут лесом со своей паранойей. Для всего остального достаточно защищённого соединения с сервером.
И вообще, мы несколько отклонились от оригинального комментария.
Против того, что, если я правильно понял берем текущую дату и получаем N сообщений, берем дату самого старого и получаем ещё N и так далее. Все одним и тем же запросом.Это почти то, что мы сделаем на сервере, но вернём номера страниц и ссылки на них. ХМРР не сможет сделать то, что вы говорите из коробки. А Пейджинг мне кажется более удобным, так ка при поиске по тексту сообщений, можно просто вернуть номера страниц, в которых этот текст встречался.
Тоже не лучшее решение, завтра(а скорее всего уже вчера, я гуглил чуток, но не нашел) появится XEP где можно будет удалять старое сообщение у всех участников чата. И тогда юзер радостно удаляет пол сотни сообщений и ломает пейджинг.
Тут два варианта — пустые страницы или скипы при попытке загрузить историю.
Тут два варианта — пустые страницы или скипы при попытке загрузить историю.
Ждём третью статью с заголовком «Ну не отстой ли XMPP?».
Хабру было бы не плохо иметь, а-ля XEP-0308: Last Message Correction для комментов.
Интересно, что в XMPP сообществе сейчас обсуждается подобная реализация MUC только используя Pub/Sub, что подтвердил мне один из участников рабочей группы.
А можете скинуть ссылку на это обсуждение? И привнесло ли это обсуждение какие-то результаты спустя год?
Мне нужно сделать мультиюзер-чат на своем Jabber-сервере с оффлайн-сообщениями, но не найду никак нормального решения кроме как использовать самописных ботов ;(
И ещё вопрос — какие-то опенсоурс-альтернативы XMPP/Jabber, где нормально реализованы групповые чаты, существуют на данный момент?
Отвечаю сам себе ;) Нашёл всё же отличную альтернативу XMPP / Jabber — открытый децентрализированный протокол [matrix] — в отличие от таких альтернатив как Rocket.Chat, Mattermost — поддерживает федерацию, т.е. общение между пользователями разных серверов. Так что если кто-то ещё мучается с умирающим жаббером — велкам в Матрицу! ;)
Sign up to leave a comment.
Отстой ли XMPP?