ВНИМАНИЕ! ОБЪЯВЛЕНИЕ!
Заплачу́ 2000 (две тысячи) рублей первому, кто напишет и добавит в апстрим (под свободной лицензией) патч для pidgin/libpurple (либо плагин для pidgin) реализующий уведомления о доставке сообщений по протоколу jabber (ака XEP-0184). Подробнее: http://developer.pidgin.im/ticket/6940 http://xmpp.org/extensions/xep-0184.html . Основание для оплаты: после очередного апдейта pidgin приобрел соответствующую фичу, либо на http://developer.pidgin.im/wiki/ThirdPar... появилась ссылка на соответствующий работающий плагин.
Странствующие программисты, сетевые бомжи и просто желающие заработать на шампусик к празднованию НГ и одновременно помочь опенсорцу — не проходите мимо! Отвлекитесь ненадолго от пиления личкрафтов и написания стопицотпервого медиаплеера!
P.S. Торг неуместен, но другие пользователи pidgin'а, заинтересованные в этой фиче, могут присоединиться к выплате.
P.P.S. Настоятельно рекомендуйте.
63 comments
recommend
bookmark
subscribe
Нет чтобы личкрафты пилить/юзать, в которых все это давно есть.
А, ну и да, пиджин говно и не нужен, и писать подобное на сишечке/ГЭТЭКА — себя не любить. Спасибо, нет, даже за миллион баксов.
пили сам
> рвущиеся конекты
> уведомления о доставке
да у тебя же X-Y PROBLEM.
Уведомления о доставке, грубо говоря, говно и не нужны. Что действительно нужно — это автоматический фетчинг глобальной по аккаунту истории с сервера, как это сделано в андроидном gtalk-клиенте.
Ошибка в наборе хромосом?
У тебя — да.
i googled it for you: http://www.perlmonks.org/?node_id=542341
На сервере нет никакой истории.
на gtalk-овском — есть.
XEP на message archiving нагугли, блеать.
Notice (2010-06-21): The XMPP Council [1] believes that the Message Archiving protocol is unduly complex and will likely request a thorough review and simplification of this specification before advancing it to Final.
Да, я знаю, я-то его читал, в отличие от.
Хотя, ты же дедфуд, ты любишь лишние переусложнения.
tl;dr, xml ⇒ хочу реферат или ничего.
Обоснуйте.
Съеби нахуй.
Хорошо.
Хороший, годный лях.
Тёплый, ламповый лях.
Запилю бесплатно, если обоснуешь, что оно нужно (я сам пользователь pidgin, и умвр).
Кстати, как оно там с крешхендлерами, и не пробовал ли ты лц в роли IM? :3
> как оно там с крешхендлерами
Толсто.
> не пробовал ли ты лц в роли IM? :3
Нет, потому что не нужен (c) (r) (tm)
:(
оно не нужно, так как TCP предоставляет гарантии доставки. И когда условия для этих гарантий не соблюдены, костылики на прикладном уровне никак не помогут.
*мне не нужен, я имею в виду. Было бы мне лично нужно — пилил бы.
Оук, в порядке соцопроса — что делает его ненужным?
тогда я U
В порядке перечисленя в списке Main features на глагне лц.орг: Firefox, pidgin, google reader, не понел (vlc, если речь про сетевой аудио/видео плеер, идею подкастов не понимаю), transmission на отдельной файлопомойке+transgui, DCPP не пользую, github :), ну ты понел, (s)mplayer/vlc по настроению.
Нууу, а почему заменять пижжином-то? ) Тем более, XMPP у нас полущ.
Почему заменять? Я его года с 2007-го пользую, это наоборот — заменять голубя лц, а меня в голубе всё устраивает.
#define полущ.
Да хотя бы XEP из /0 поддерживается. И ваще, http://leechcraft.org/plugins-azoth-xoox
зачем мне всё это, если я жабир использую как drop-in replacement асичке и чтобы в жуйк/пстач срать?
Пстачеплагин вон тоже годный. И жуйкоплагин. И ваще, give it a try, нам такие погромизды, как ты, нужны, нам нужна твоя душа!
идея подкастов в том, что это такое радио, серии которого ты можешь слушать в любое удобное для тебя время. Весьма часто это просто записи эфиров, выкладываемые в RSS; но не всегда.
уже продал тёмным богам хаоса ок
а разве нельзя просто зайти на сайт (любого) радио и скачать заботливо выложенные админами архивные записи? Да ещё и rss, mother of god. не понимат
Пиздец.
Што.
ну вот примерно это оно и есть. Архив радиоэфиров.
Единственная тонкость в том, что эфиров может в принципе не быть. Например, ватага школьников может просто раз в неделю орать в микрофон всякую хреноту, и выкладывать записи mp3. Другие школьники (из общей школы, например), может эти mp3 скачивать и слушать в транспорте.
Dare I say хуита какая-то?
просто на любителя. Не все же любят читать газеты? Но от этого газеты хуитой не становятся.
okay
У меня тоже все работало, пока по какой-то хуите не начали пропадать реплики в разговорах. КОннект был нормальный вроде. Короче, начал замечать такую фичу иногда. И вроде бы уже люто-бешенно ее реквестировал тут.
TCP предоставляет не гарантию доставки, а всего-лишь уведомление в случае удачной доставки, это раз. Во вторых, это уведомление доставки не к remote recipient, а только к серверу, который, не будет посылать тебе уведомление о том доставлено ли сообщение и, скорее всего, даже не будет посылать его повторно если не получит TCP ACK. Ну а XEP в /0 как раз решает проблему end-to-end acknowledge. Так от чего "костылики на прикладном уровне не помогут"?
orly, а повторную отправку кто делает?
доставка к серверу — ну и отлично! пусть записывает себе в историю и заботится о дальшейшей маршрутизации месаджа.
в ололо-распределённой сети хотеть знать что-то большее о маршруте месаджа просто странно.
И опять же, в схеме «xmpp-клиент говорит другому xmpp-клиенту по xmpp-протоколу, что предыдущее xmpp-сообщение получил», а xmpp-сервера пассивно гоняют эти xmpp-месаджи туда-сюда только мне одному видятся потоки излишнего иксэмеля? не проще ли открыть прямое TCP соединение между клиентами и общаться по нему? Какую функциональность тут вообще несёт дополнительный, «прикладной» уровень абстракции?
Я считаю, что если в ваших юз-кейсах для IM часто рвутся низлежащие подключения и urn:xmpp:ping вас не удовлетворяет — вы ошиблись с выбором XMPP.
ПОТОКИ ИЗЛИШНЕГО ИКСЕМЕЛЯ
да-да, ваши любимые базворды
Дибас и питон забыл.
> orly, а повторную отправку кто делает?
ВНЕЗАПНО, но кто тебе гарантирует что со второй попытки данные будут доставлены? а хоть с третьей?
> доставка к серверу — ну и отлично! пусть записывает себе в историю и заботится о дальшейшей маршрутизации месаджа.
было бы хорошо, да, если бы такое поведение было закреплено законодательно. Но при этом всё равно надо какое-то уведомление о доставке на уровне xmpp, потому что, afaik, у приложения нету способа узнать какие данные не были доставлены (приложение просто получает -1 в ответ на write и какой-то код в errno), а в следствие этого, получаем дополнительный вектор DoS-атаки — посылку сообщений клиенту, который не отвечает на них уведомлениями о доставке (это решается лимитами, но тогда мы опять теряем гарантию доставки сообщения адресату). Впрочем, подобная атака возможна даже если есть способ узнать какие данные не были доставлены, берём клиента который не посылает TCP ACK и шлём ему сообщения: содениение будет разрываться после таймаута, но сервер все равно вынужден держать все сообщения в памяти чтобы послать их заново при повторном подключении клиента. Но всё равно, кто гарантирует доставку в случае падения сервера или просто отключения питания? Как не крутись, больше чем end-to-end acknowledgement не получишь, так почему не иметь хотя бы это?
> в ололо-распределённой сети хотеть знать что-то большее о маршруте месаджа просто странно.
маршрут никому и не нужен, нужно уведомление о доставке. Да и в случае XMPP маршрут всегда в себя включает не более 2 серверов между общающимися клиентами.
> xmpp-сервера пассивно гоняют эти xmpp-месаджи
TCP/IP именно так и работает: роутеры гоняют "пассивно" IP-пакеты, не запоминая никакого состояния, всё остальное ложится на плечи тех, кто пытается общаться с какими-то гарантиями. Дизайн "тупая сеть — умные endpoints" по очевидным причинам более устойчив к разного рода атакам и отказам частей сети чем "умная сеть — тупые endpoints".
> только мне одному видятся потоки излишнего иксэмеля?
XMPP практически весь состоит из излишних потоков XML'я >_>
> не проще ли открыть прямое TCP соединение между клиентами и общаться по нему? Какую функциональность тут вообще несёт дополнительный, «прикладной» уровень абстракции?
Не всегда есть такая возможность. В IRC была предусмотрена такая возможность в виде DCC. И в XMPP тоже можно такое сделать, и даже лучше, из-за наличия поддерржки SOCKS-прокси, но, видимо, это никому не нужно.
> Я считаю, что если в ваших юз-кейсах для IM часто рвутся низлежащие подключения и urn:xmpp:ping вас не удовлетворяет — вы ошиблись с выбором XMPP.
Возможность получения уведомлений о доставке отправленного сообщения — это не что-то странное, а вполне закономерное требование. Олсо, есть мнение (и не безосновательное) что XMPP — это одна большая ошибка.
> ВНЕЗАПНО, но кто тебе гарантирует что со второй попытки данные будут доставлены? а хоть с третьей?
внезапно, и чем в этом случае end-to-end acknowledgement — который не придёт — лучше не пришедшего пинга на сервер?
абзац про атаку не понял.
> TCP/IP именно так и работает: роутеры гоняют "пассивно" IP-пакеты, не запоминая никакого состояния
мечты-мечты. Это в идеале так, а точнее если смотреть на абстракции TCP/IP «сверху». Ниже у нас найдутся всякие радости вроде ната, умных файрволов, FTP и прочего. И мне непонятно, почему endpoints вдруг отделились от сети и в одних случаях стали называться «умными», а в других — «тупыми».
> не проще ли открыть прямое ... видимо, это никому не нужно.
ну да, для ipv4-то понятно, где нат в нате сидит и подсети для натов раздаёт.
> Возможность получения уведомлений о доставке отправленного сообщения — это не что-то странное, а вполне закономерное требование.
Скажем так, иногда ещё всплывающий фичреквест.
Расскажу ещё раз: андроидный клиент гуглотолка эту проблему решает просто замечательно (а андроидомобильнички практически обязательно сталкиваются с разрывами связи при движении: роуминги между вайфаем и сотовой сетью, туннели метро этц). Как только клиент детектит потерю связи с сервером, в диалогах появляется маленькая красненькая надпись: «Связь потеряна, сообщения будут доставлены после возврата в онлайн». При собственно возврате производится синхронизация с историей сервера: все недополученные сообщения принимаются, все отосланные (с точки зрения сервера, то есть включая и других клиентов/ресурсов) добавляются, если есть что ещё отослать — отсылается.
Ничего нигде не проёбывается, всё просто работает™.
Правда, глупый пиджин не умеет так круто забирать историю, потому здесь не всё так гладко.
Пиздец костыль.
Хм, пойти что ли прикрутить уже message archiving. Правда, этот XEP говно, и разрабатывал его какой-то пьяный сантехник, не знакомый с паттернами проектирования вообще.
а индикация типа ВОТ ВОТ ЭТА СТРОЧКА, ПОХОЖЕ, ЕЩЁ НАВЕРНОЕ НЕ ДОШЛА, МОЖЕТ БЫТЬ, А, И ЭТИ СЛЕДУЮЩИЕ ДВЕ ТОЖЕ НАВЕРНОЕ НЕ ДОШЛИ ПОКА, которую половина пользователей не поймёт без подсказки — лучше?..
и надстройка в протоколе прикладного уровня, точь-в-точь повторяющая фичу транспортного уровня — не костыль? Странное у тебя мнение.
Ты еще забыл про совместимость разных версий XEP'ов на delivery receipts — вернее, про отсутствие таковой. Поэтому, например, говноgajim не понимает, что до личкрафтов сообщения доходят.
ну это как бы общая болезнь всего xmpp, хотя конкретный пример тоже интересен.
>Я считаю, что если в ваших юз-кейсах для IM часто рвутся низлежащие подключения и urn:xmpp:ping вас не удовлетворяет — вы ошиблись с выбором XMPP.
Так толсто, что даже тонко.
Я считаю, что если вы используете XMPP — вы ошиблись с выбором XMPP.
Вот это — толстота, что тонкота. А у него нормик.
s/толстота/хуита/g
> внезапно, и чем в этом случае end-to-end acknowledgement — который не придёт — лучше не пришедшего пинга на сервер?
Хотя бы тем, что повторная отправка ложится на плечи отправителя, а не сети. И тем, что отправитель может точно знать что его сообщение доставлено.
> абзац про атаку не понял.
Если кратко, мы получаем или уязвимую к выеданию всей доступной памяти сеть, или не получаем гарантий доставки.
> мечты-мечты. Это в идеале так, а точнее если смотреть на абстракции TCP/IP «сверху». Ниже у нас найдутся всякие радости вроде ната, умных файрволов.
Но это всё костыли, при чём необязательные. А если ты хочешь NAT или stateful packet filtering, то тебе, ясен хрен, надо лазить внутрь L4 чтобы отличать разные соединения. Это никак не отменяет того, что базовая задача IP-сети — доставлять пакеты без каких либо гарантий, остальное — задача endpoint'ов, которым это нужно.
> И мне непонятно, почему endpoints вдруг отделились от сети и в одних случаях стали называться «умными», а в других — «тупыми».
Потому что они в рассматриваемой ситуации не являются транзитными узлами сети, а только потребителями. "умные" и "тупые" — в зависимости от того, кто берёт на себя дополнительные действия для хоть какого-то обеспечения доставки данных. В одном случае этим занимается endpoint, а сеть просто предоставляет возможность доставки пакета (может дойдёт, а может и нет). В другом — клиент просто посылает данные, а о том чтобы они были доставлены заботятся транзитные узлы.
> ну да, для ipv4-то понятно, где нат в нате сидит и подсети для натов раздаёт.
Почему ты считаешь что для других протоколов всегда есть возможность установить прямую связь между любыми двумя точками? Даже для ipv6 провайдер вполне может фильтровать входящие соединения и требовать за отключение фильтрации дополнительную плату.
> костылики на прикладном уровне никак не помогут.
> Как только клиент детектит потерю связи с сервером, в диалогах появляется маленькая красненькая надпись: «Связь потеряна, сообщения будут доставлены после возврата в онлайн». При собственно возврате производится синхронизация с историей сервера
Хех, а что это тогда, как не "костылики на прикладном уровне"?
Впрочем, это вполне годный вариант, но здесь от клиента требуется чуть больше чем просто послать сообщение (но это не проблема) и чтобы это работало надо чтобы все сервера хранили историю, но это не закреплено в XMPP-IM, потому может быть реализовано только в очень отдалённом будущем.
Почему надо чтобы все хранили? Потому что иначе при обрыве соединения между серверами сообщения тоже будут потеряны (и как здесь делать синхронизацию?), как и при обрыве соединения между сервером получателя и самим получателем. Так что этот метод спасает только от одной из возможныз неприятностей: разрыва соединения между отправителем и сервером. Если оба сервера пишут историю — то это спасает и от разрыва между получателем и его сервером. Но проблема с разрывом между серверами все равно остаётся. Ну и да, кто помешает засрать историю сообщений? Кластер для хранения истории есть далеко не у всех.
как-то похуй
кстати, @gelraen здесь по большему счёту был прав.
блядь, я здесь какие-то длинные простыни писал. tl;dr
Тока когда оно появится в ticket/6940 отпишитесь плиз кто-нибудь в этой теме, хочу тупо засечь, за сколько дней/недель тикет пятилетний закроют за 2000р и кому действительно нужен pidgin и azoth и XEP-0184 и блять нахуй я это написал