Прощай net-im/psi - ты всегда был хорошим джаббер клиентом

Если до 1 апреля сего года у psi не появится майнтайнер, который обновит и приведет в соответствие текущим реалиям ебилд psi - начнется процесс удаления ебилда из дерева.

P.S ебилд в дереве, но пока что без плюсов; Ждем, надеемся и верим.

>Из моей практики они

>Из моей практики они совершенно замечательно работают. Хотя я в основном пользуюсь асечным шлюзом. И там работают и разного рода нстроения с допстатусами и отчёты о доставке

Как раз сегодня загнулся очередной :) За несколько месяцев третий на моей памяти. И, что печально, переход на новый шлюз это сотни геморроя. Начиная с нескольких сотен кликов подтверждения авторизации, процесс предполагает ручную чистку ростера от дубликатов и последующее переименование файлов истории. Приятно провел час :)

Ретроспективно наглядно видно, что лучше потратить время на установку собственного ejabberd + pyicqt. Глядишь, и скайпа прикрутить как-нить получится.

Да, и камень в огород пси — он, как и пиджин, непонятно как реагирует на проблемы со связью. Было зарегистрировано, что при переподключении VPN провайдера пси никак на это не отреагировал и продолжал «доставлять» сообщения — в никуда. Проприетарный скайп, в то же время, с ситуацией справился.

Beelzebubbie написал(а):>Из

Beelzebubbie написал(а):
>Из моей практики они совершенно замечательно работают. Хотя я в основном пользуюсь асечным шлюзом. И там работают и разного рода нстроения с допстатусами и отчёты о доставке

Как раз сегодня загнулся очередной :) За несколько месяцев третий на моей памяти. И, что печально, переход на новый шлюз это сотни геморроя. Начиная с нескольких сотен кликов подтверждения авторизации, процесс предполагает ручную чистку ростера от дубликатов и последующее переименование файлов истории. Приятно провел час :)

Вродебы на данном сервере всё пока что стабильно работает. если что - ясно кого потыкать. У проблемы переезда, есть элегантное решение. Перед регистрацией на новом шлюзе нужно включить "автоматическую авторизацию контактов" и "автоматически открывать входящие сообщения". После этого моно зарегаться на новом транспорте и наслаждаться сотнями месаг летающих туда-сюда. :)

Beelzebubbie написал(а):
Ретроспективно наглядно видно, что лучше потратить время на установку собственного ejabberd + pyicqt. Глядишь, и скайпа прикрутить как-нить получится.

Да, и камень в огород пси — он, как и пиджин, непонятно как реагирует на проблемы со связью. Было зарегистрировано, что при переподключении VPN провайдера пси никак на это не отреагировал и продолжал «доставлять» сообщения — в никуда. Проприетарный скайп, в то же время, с ситуацией справился.

В Psi есть "подтверждения доставки"

>Вродебы на данном сервере

>Вродебы на данном сервере всё пока что стабильно работает. если что - ясно кого потыкать.
Ну я рассматривал не конкретный сервер. кроме того, с учетки на xmpp.ru я не могу пользоваться этим шлюзом. Проблема в том, что нужно быть готовым к переезду в любой момент.

>У проблемы переезда, есть элегантное решение
ну с окошками это поможет, однако вычищение старых контактов и «перелинковка» истории останется для ручек. Если контактов 10, то не проблема. Если их 400+ — проблема.

>В Psi есть "подтверждения доставки"
XEP-0079, XEP-0184? Имеется в виду «request/send receipts»? Я немного о другом — возможно, я чего-то не понимаю, однако меня дико удивляет, что сообщение вообще может вести себя как «отправленное» при отсутствии реального соединения с сервером. И вообще, мне кажется крайне нелогичным то, что IM клиент игнорирует проблемы с сетью. Уже не раз сталкивался, что при возникновении подобных проблем что пси, что пиджин _никак_ на это не реагируют. Никакой визуализации, никаких предупреждений. Конечно, в конце концов, по-видимому, происходит переподключение, но я ни разу этого не видел — стало быть, «время реакции» составляет сотни секунд. А в течение этого времени можно спокойно отправлять сообщения.

/

Beelzebubbie написал(а):
Я немного о другом — возможно, я чего-то не понимаю, однако меня дико удивляет, что сообщение вообще может вести себя как «отправленное» при отсутствии реального соединения с сервером. И вообще, мне кажется крайне нелогичным то, что IM клиент игнорирует проблемы с сетью. Уже не раз сталкивался, что при возникновении подобных проблем что пси, что пиджин _никак_ на это не реагируют. Никакой визуализации, никаких предупреждений. Конечно, в конце концов, по-видимому, происходит переподключение, но я ни разу этого не видел — стало быть, «время реакции» составляет сотни секунд. А в течение этого времени можно спокойно отправлять сообщения.

1. Проверить проблему на воспроизводимость с ещё некоторым количеством клиентов (два это только "совпадение", надо хотя бы три, а лучше для ровного счёта четыре).
2. Детально описать условия проявления бага (обязательно с достаточным описанием способа наблюдения, в идеале --- с приведением хотя бы одного способа воспроизведения бага последовательностью _твоих_ действий) и выложить для начала на форуме.
Насколько я понял, оно проявляется при переподключении на стороне провайдера (изменении параметров подключения при пренебрежимо малом времени неработоспособности канала), так?
3. Надлежащая проработка п.2 должна изрядно помочь в главном: в открытии соответствующего бага в родном трекере.

ЗЫ: И не стесняйся указывать условия, при которых оно критично.

:wq
--
Live free or die

Beelzebubbie

Beelzebubbie написал(а):
evadim написал(а):
В Psi есть "подтверждения доставки"

XEP-0079, XEP-0184? Имеется в виду «request/send receipts»? Я немного о другом — возможно, я чего-то не понимаю, однако меня дико удивляет, что сообщение вообще может вести себя как «отправленное» при отсутствии реального соединения с сервером. И вообще, мне кажется крайне нелогичным то, что IM клиент игнорирует проблемы с сетью. Уже не раз сталкивался, что при возникновении подобных проблем что пси, что пиджин _никак_ на это не реагируют. Никакой визуализации, никаких предупреждений. Конечно, в конце концов, по-видимому, происходит переподключение, но я ни разу этого не видел — стало быть, «время реакции» составляет сотни секунд. А в течение этого времени можно спокойно отправлять сообщения.

А ему информацию эту откуда брать? Через libastral? Проблемы с сетью - штука очень разноплановая, и если тебе нужно более-менее убедиться что сообщение реально дошло - есть тот самый XEP-0184. Psi нормально реагирует на проблемы с сервером, посредством обычных сетевых таймаутов, после чего начинает переподключаться. Как с технической стороны описать те самые "проблемы с сетью" ? Откуда клиенту знать что сети нет - постоянно накручивать трафик пингуя какимнибудь образом сервер? Получать сообщения от NM/Wicd/whatever ? Тот же Skype постоянно жрёт трафик когда он сети - p2p есть p2p, но даже там у меня бывают сообщения не доходят. Также, у меня одна из учёток настроена через http-poll и при пересоединении и длительных лагах сети сообщения всёравно дойдут. Разные клиенты, карные сети, разные ОС - всё это сильно влияет на результат.

Клиент должен контролировать

Клиент должен контролировать не наличие сети, а статус доставки: доставлено на сервер - ок, иначе предупредить что твою писанину видишь только ты сам.
например, в kopete видно те сообщения которые отправлены, но не доставлены до сервера.

_SerEga_ написал(а): Клиент

_SerEga_ написал(а):
Клиент должен контролировать не наличие сети, а статус доставки: доставлено на сервер - ок, иначе предупредить что твою писанину видишь только ты сам.

В XMPP-сетях реальна ситуация, когда ты доставишь своему серверу, а он дальше передаст, и оно например между 2мя серверами завянет. Или до клиента не долетит.

_SerEga_ написал(а):
например, в kopete видно те сообщения которые отправлены, но не доставлены до сервера.

О чём и говорилось выше - в XMPP есть для этого несколько протоколов.

все это замечательно и

Все это замечательно и очевидно (по большей части), однако практические опыты показывают фундаментально неверное поведение. Кроме того, я употребляю «проблемы с сетью» не как синоним отсутствия соединения с конкретным сервером, а как его причину и надмножество. Про «посредством обычных сетевых таймаутов» гипотеза не подтверждается, что показывается ниже. Жрет трафик? И сколько же он таким образом сожрет? На рубль за месяц?
Вкратце опишу их:

опыт 1
вытаскиваем сетевой кабель и пишем сообщения. сообщения «отправляются», никакой реакции на невозможность доставки не обнаруживается (что _уже_ нехорошо). Светлый момент в этом только один — после восстановления подключения сообщения доставляются. Сети не было минуты три.

опыт 2 (проведен мною и Анархистом, поочередно, при схожих сетевых конфигурациях)
Переустанавливаем подключение к провайдеру (в моем случае на роутере переподключаю L2TP, у Анархиста ADSL'у делается ресет)
Пишем пару раз в минуту сообщения и глядим на реакцию. Реакции никакой. Попытка использовать Service Discovery не завершается успехом, но и не выдает ошибку. Через минуту интернеты есть, но ничего не меняется. Только через 15-18 минут psi наконец переподключается и, разумеется, ничего не доставляет из написанного (это отличие от первого случая я склонен объяснять сменой IP). Ошибок никаких тоже, с его точки зрения, не произошло. Скриншоты заверены.

Проблема налицо — факт доставки/недоставки сообщений никак не контролируется. Мне удивительно видеть, что в данном случае игнорируются даже базовые возможности TCP по контролю доставки пакетов (где Вы видели такие таймауты и чем может быть обусловлено в данном случае его значение, большее, чем полминуты?)

Наблюдения «из жизни». Поскольку мой провайдер считает, что инициировать несколько раз в день переключение VPN — суть хорошо, я довольно часто сталкиваюсь с тем, что сообщения приходят на андроида (подключенного по воздуху к тому же роутеру) бесперебойно и достаточно вовремя (андроидный клиент быстро соображает о необходимости переподключения), а вот на десктоп таки приходит не все. Судя по всему, в этом есть все же огромный плюс — я экономлю несколько КБ трафика в день на keep-alive, потому что мой клиент считает что это важнее пропущенных при приеме и доставке сообщений. Я один не согласен с
этим или все же нет?
Ранее использовавшиеся мной мультипротокольные клиенты под Win не обнаруживали такого любопытного поведения, были разве что нарекания на ложноотрицательную (изредка) реакцию на проблемы с соединением с сервером, индикация проблем присутствовала.

В окончание добавлю, что пару лет назад я делал простенький бот на xmpppy, рассылающий сообщения и использующий в том числе траспорты ICQ и MRIM — и никаких проблем с определением даже более сложных проблем с недоставкой сообщений через транспорт, не испытывал. Странно думать, что разработчики psi не в состоянии реализовать детекцию проблемы доставки и переключить статус в оффлайн после контрольного неудачного выстрела по серверу.

.

Beelzebubbie написал(а):
опыт 2 (проведен мною и Анархистом, поочередно, при схожих сетевых конфигурациях)
Переустанавливаем подключение к провайдеру (в моем случае на роутере переподключаю L2TP, у Анархиста ADSL'у делается ресет)
Пишем пару раз в минуту сообщения и глядим на реакцию. Реакции никакой. Попытка использовать Service Discovery не завершается успехом, но и не выдает ошибку. Через минуту интернеты есть, но ничего не меняется. Только через 15-18 минут psi наконец переподключается и, разумеется, ничего не доставляет из написанного (это отличие от первого случая я склонен объяснять сменой IP). Ошибок никаких тоже, с его точки зрения, не произошло. Скриншоты заверены.

Стоит добавить, что на одной стороне был "тестовый" net-im/psi, на другой --- "стабильный".
Также помним, что проблема наблюдается не только с net-im/psi, но с учётом комментария про копыто --- не везде.

Ты не находишь, что обсуждения требований к IM в принципе и xmpp в частности (а заодно вопроса надлежащести качества реализации) было бы правильнее вынести в отдельную тему?

:wq
--
Live free or die

Beelzebubbie

Beelzebubbie написал(а):
>>Требование мультипротокольности в принципе по мне как минимум спорно
Провоцируешь на низкоинтеллектуальную полемику? ;)

Не "низко", а _высоко_.
Анализ базиса --- штука не только весьма дорогая.
Но если ей пренебречь и начать делать без предварительной разработки проекта, то ты рискуешь вместо поиска правильного ответа искать результат, оправдывающий затраты труда.

Beelzebubbie написал(а):
_Свое_ обоснование я уже приводил. Само существование и популярность таковых клиентов должна навести тебя на мысль, что это кому-то нужно.

Концепт вечного двигателя в своё время был весьма популярен. Рудименты этой популярности встречаются и доныне.
Так что ни популярность, ни тем более существование не являются доказательством правильности.

Beelzebubbie написал(а):
собственно я это не придумал, а пользовался. и таки удобно и логично. если сообщение не доставлено — почему оно должно попасть в историю и _зачем_?

Это не ответ на вопрос о логике отработки возврата _нескольких_ сообщений.
Зачем почтовый клиент сохраняет сообщение независимо от факта доставки?

Beelzebubbie написал(а):
Кроме того, удобно переотправить когда поднимется соединение etc. В чем разница между 1 и 2 сообщениями в этом смысле?

Поле ввода у тебя одно.

Beelzebubbie написал(а):
>>Чтобы после облома с часовой задержкой повторная попытка производилась через два часа? :)
Ерничаем? :) Тоже не придумано, а взято «из жизни» — к примеру от 5с задержка увеличивается до 60с.

Несомненно :)
Надо же тебя приучить сказав А хотя бы обозначить остальные буквы.
В данном случае: когда, как и в каком диапазоне целесообразно увеличение задержки переподключения?

Beelzebubbie написал(а):
вполне очевидно, что парсить кучу файлов в разных каталогах плюс производить среди них поиск — реализуемо, но гораздо сложнее чем что-то наподобие обычного браузинга SQL запроса к БД. Интерфейс стандартнее некуда.

Ты очевидно сравниваешь некоторую физическую реализацию файловой истории с идеальной проекций истории в БД.
И игнорируешь мои вопросы.

Beelzebubbie написал(а):
>>С бардаком в мышлении надо бороться, а не стимулировать!
надо полагать, что уважаемый может держать в голове сотни ников, уинов и прочего? остается только поздравить и отойти в сторону, восхищенно ковыряясь где-нибудь.

Сколько нужно?
И, отвечая на другую реплику: структура должна учитывать наличие у одного и того же человека нескольких учётных записей (в одной или нескольких сетях).
Про чятики тоже забывать нельзя.

Beelzebubbie написал(а):
>>Рекомендую почитать результаты попыток разработки транспорта в скайп.
на ведроиде я вполне-таки пользуюсь в мультипротокольном клиенте учетками скайпа, на винде тоже пользовался. исходя из этого полагаю, что каких-либо серьезных противопоказаний просто не существует.

Угу...
Лично мне здесь на ум приходит история с MUC в ICQ.

:wq
--
Live free or die

>Не "низко", а

>Не "низко", а _высоко_.
скорее — «не полемику, а демагогию». судя по результатам. :D

>Анализ базиса
не будем тень на плетень наводить. суть мультипротокольного клиента — сокрытие (зачастую ненужных) особенностей сонма протоколов. Единообразный подход к IM, если хочешь. Тривиальнее некуда.

>как и в каком диапазоне целесообразно увеличение задержки переподключения?
очевидно, это зависит от желания пользователя. Очевидно, что кратковременные сбои должны завершаться оперативным пересоединением, а при долговременных не нужно ломиться каждые несколько секунд.

> очевидно сравниваешь некоторую физическую реализацию файловой истории с идеальной проекций истории в БД.
Очевидно здесь другое — изначально такой формат (файлы, html/xml) истории был выбран без учета того, что он будет впоследствии активно использоваться самим приложением. Поэтому без смены формата реализовать более богатый функционал не удастся.

>Сколько нужно?
А существует некоторая опосредованная универсальная цифра? :D Вообще-то я говорил о недоступности поиска по атрибутам контакта, что является серьезным недостатком. IM-клиент это отнюдь не утилита для решения конкретной задачи — это инструмент, позволяющий решать множество вопросов, посему чем шире функционал и настраиваемость, тем лучше.

>MUC в ICQ
можно сколько угодно критиковать любые протоколы и их темные стороны — тем не менее, пока они широко используются, их поддержка необходима. Оппонент начинает склоняться к демагогии — обычно это признак скорого израсходования аргументов ;)

.

Beelzebubbie написал(а):
>Не "низко", а _высоко_.
скорее — «не полемику, а демагогию». судя по результатам. :D

Намекаешь на то, что "Всякая сложная проблема имеет простое, очевидное, неправильное решение."? :)

Beelzebubbie написал(а):
>Анализ базиса
не будем тень на плетень наводить. суть мультипротокольного клиента — сокрытие (зачастую ненужных) особенностей сонма протоколов. Единообразный подход к IM, если хочешь. Тривиальнее некуда.

Практически: выравнивание функциональности по самому убогому (на стороне которого может играть ТМО, и который извлекает из такого подхода выгоду сохранения статуса гегемона).
Даже без постановки вопроса о том, скова (что) нужно.
Действительно, тривиальнее некуда.

Beelzebubbie написал(а):
> очевидно сравниваешь некоторую физическую реализацию файловой истории с идеальной проекций истории в БД.
Очевидно здесь другое — изначально такой формат (файлы, html/xml) истории был выбран без учета того, что он будет впоследствии активно использоваться самим приложением. Поэтому без смены формата реализовать более богатый функционал не удастся.

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

Beelzebubbie написал(а):
Вообще-то я говорил о недоступности поиска по атрибутам контакта, что является серьезным недостатком.

Никогда им не пользовался и не испытывал потребности.

Beelzebubbie написал(а):
IM-клиент это отнюдь не утилита для решения конкретной задачи — это инструмент, позволяющий решать множество вопросов, посему чем шире функционал и настраиваемость, тем лучше.

С точки зрения философии Unix ты несёшь откровенную ересь :)

Beelzebubbie написал(а):
>MUC в ICQ
можно сколько угодно критиковать любые протоколы и их темные стороны — тем не менее, пока они широко используются, их поддержка необходима. Оппонент начинает склоняться к демагогии — обычно это признак скорого израсходования аргументов ;)

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

Фишка в том, что фича MUC _протоколом_ ICQ предусматривается.
Но практически её никто не пользуется, потому что реализована она (была?) только в родных клиентах (причины ты сам красиво озвучил), которыми по понятным причинам... мало кто пользуется.

Вообще плясать надо (особенно в случае многопротокольных клиентов) от списков необходимого/желательного/опционально функционала.
Про гугл талк сотоварищи полагаю крайне полезным рассмотрение вопроса степени совместимости с родителем (xmpp).

:wq
--
Live free or die

>Намекаешь на то, что "Всякая

>Намекаешь на то, что "Всякая сложная проблема имеет простое, очевидное, неправильное решение."? :)
_сложной_ проблемы здесь нет. я уже слегка устал повторять — но я описываю в основном уже где-то имеющийся функционал. И, к слову — отсутствие решения вообще слегка хуже его частичного наличия.

>…выравнивание функциональности по самому убогому
а с чего ради-то? откровенная ерунда. Что, если у протокола XXX нет Service Discovery, то мультипротокольный клиент почему-то не может это использовать в XMPP?

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

>Никогда им не пользовался и не испытывал потребности.
тут и возразить нечего. соседский кот, например, не пользуется IM вообще — включим и его мнение в обсуждение?

>С точки зрения философии Unix ты несёшь откровенную ересь :)
c точки зрения здравого смысла и рассмотрения перспектив самосовершенствования — быть ортодоксом суть архивредно :D

Оппонент то забегает вперед телеги, то прячется обратно. То мультипротокольность есть «выравнивание функциональности по самому убогому», то «полагаю крайне полезным рассмотрение вопроса». Интегрально-конструктивное мнение у оппонента вообще наличествует?

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".