Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Я думаю что все дело в том что если клиенты не авторизованы — нет возможности определить находится ли определённый ресурс онлайн. По-этому Миранда считает что неизвестное состояние это оффлайн и отправляет сообщение на JID без ресурса. Насколько я понял RFC не описывает что нужно делать в ситуации когда не известно или ресурс онлайн или оффлайн. По-этому решение Миранды имеет смысл и не нарушает RFC. Хотя и Psi на самом деле не нарушает, так как данный аспект поведения не указан RFC.
If the message is being sent in reply to a message previously received from an address of the form <user@domain/resource> (e.g., within the context of a chat session), the value of the 'to' address SHOULD be of the form <user@domain/resource> rather than of the form <user@domain> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available.Это разве не значит что удалять ресур нужно только в случае если было получено presence сообщении о отсутсвии?
Тут нельзя однозначно прочитать. Так как изначально не было получено presence сообщение о присутствии, то можно сказать что по умолчанию ресурс не был доступен и соответсвенно the sender has knowledge (via presence) that the intended recipient's resource is no longer available.
Тут ведь не сказано что отправитель должен получить уведомленее о том что ресурс получателя недоступен, а только то что он должен принять решение на основе знаний об этом.
Тут ведь не сказано что отправитель должен получить уведомленее о том что ресурс получателя недоступен, а только то что он должен принять решение на основе знаний об этом.
тут видимо дело в значении по умолчанию, как всегда :)
Мне не понятно почему miranda(да и другие клиенты) делают то что они делать не объязаны? если они не отрезают ресурс то с доставкой оффлайновых сообщений хорошо справиться сервер, благо это в рфц описано и ejabberd(на нем я тестировал) эти рекомендации соблюдает.
Мне не понятно почему miranda(да и другие клиенты) делают то что они делать не объязаны? если они не отрезают ресурс то с доставкой оффлайновых сообщений хорошо справиться сервер, благо это в рфц описано и ejabberd(на нем я тестировал) эти рекомендации соблюдает.
Ну опять же. RFC в виде требования (то есть SHOULD) пишет:
the value of the 'to' address SHOULD be of the form <user@domain/resource> rather than of the form <user@domain> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available.
Миранда и другие клиенты не могут воспринимать єто как рекомендацию, так как это не рекомендация а требование.
Скорее всего требование реализуется в них как:
if(presence == Offline) {
отправить без ресурса
} else {
отправить с ресурсом
}
Тут вся проблема состоит в том, или считать неавторизованного отправителя Offline. Миранда считает, Пси — нет. Что правильнее — сложно сказать, RFC не дает даже рекомендаций. (По крайней мере исходя из тех цитат что вы привели здесь.)
the value of the 'to' address SHOULD be of the form <user@domain/resource> rather than of the form <user@domain> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available.
Миранда и другие клиенты не могут воспринимать єто как рекомендацию, так как это не рекомендация а требование.
Скорее всего требование реализуется в них как:
if(presence == Offline) {
отправить без ресурса
} else {
отправить с ресурсом
}
Тут вся проблема состоит в том, или считать неавторизованного отправителя Offline. Миранда считает, Пси — нет. Что правильнее — сложно сказать, RFC не дает даже рекомендаций. (По крайней мере исходя из тех цитат что вы привели здесь.)
вот как раз если бы было так как вы написали то это случай с psi. миранда же делает
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
имхо null != offline
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
имхо null != offline
Я описал работу как она по идее должна быть по RFC, подразумевая что такое сравнение должно быть во всех клиентах, включая и Миранду и Пси.
Потом я попробовал пояснить в чем разница в моем понимании:
> Тут вся проблема состоит в том, или считать неавторизованного отправителя Offline. Миранда считает, Пси — нет.
Смысл в том что на момент сравнения значение presence не определено, по этому все зависит от того как клиент обрабатывает неопределённое значение. Этого нет в RFC.
Потом я попробовал пояснить в чем разница в моем понимании:
> Тут вся проблема состоит в том, или считать неавторизованного отправителя Offline. Миранда считает, Пси — нет.
Смысл в том что на момент сравнения значение presence не определено, по этому все зависит от того как клиент обрабатывает неопределённое значение. Этого нет в RFC.
ИМХО вы как раз описали работу psi, а у миранды обратная ситуация:
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
null != offline
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
null != offline
RFC 2119:
SHOULD This word, or the adjective «RECOMMENDED», mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Как видите, это вовсе не требование.
SHOULD This word, or the adjective «RECOMMENDED», mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Как видите, это вовсе не требование.
Спасибо!
Довольно интересно, не совсем соответствует значению слова не применимо к RFC насколько я понимаю, ну да ладно :)
Тогда как я понимаю вообще нет проблемы в том плане что в клиентах (Миранде) баг реализации, так как рекомендацию можно выполнять, а можно и нет.
Довольно интересно, не совсем соответствует значению слова не применимо к RFC насколько я понимаю, ну да ладно :)
Тогда как я понимаю вообще нет проблемы в том плане что в клиентах (Миранде) баг реализации, так как рекомендацию можно выполнять, а можно и нет.
SHOULD это конечно рекомендация. Но рекомендациям можно не следовать только если на то есть объективные причины. Я не вижу объективных причин отбрасывать ресурс при ответе на сообщение :) Забота о доставке сообщения отпадает потому как этим может заняться Jabber сервер. Есть какие либо другие серьезные причины что бы отвечать на JID без ресурса?
Ну опять же. RFC в виде требования (то есть SHOULD) пишет:
SHOULD — это не требование, а рекомендация:
SHOULD
This word, or the adjective «RECOMMENDED», mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
согласно принятым соглашениям в RFC (http://www.faqs.org/rfcs/rfc2119.html)
Миранда не запоминает ресурсы для оффлайновых контактов не из ростера, но для «нормальных» доступен как выбор непосредственно нужного ресурса, так и работа в режимах «Последний активный» и «На выбор сервера», что не во всех клиентах присутствует :)
Объясните, пожалуйста, хотя-бы в кратце зачем нужно столько хитростей? Не авторизованные, оффлайновые, да еще и с 1 джида? Возможно, мы что-нибудь придумаем :)
Объясните, пожалуйста, хотя-бы в кратце зачем нужно столько хитростей? Не авторизованные, оффлайновые, да еще и с 1 джида? Возможно, мы что-нибудь придумаем :)
Спасибо, но эту часть задачи я пока решил без использования jabber :( Все эти хитрости не казались мне хитростями потому как я считаю протокол все их предусматривал и никаких недокументированных возможностей я не использовал :) Если бы jabber клиенты вели себя так как я ожидал то решение было довольно красивое…
Жаль, что не получилось Вам помочь :)
Все эти хитрости не казались мне хитростями потому как я считаю протокол все их предусматривал и никаких недокументированных возможностей я не использовал :)Хитрости — это то, чего 99% пользователей не использует. Неважно что написано в протоколе: если фича никем не используется, то она, скорее всего, не будет реализована. Или будет реализована с ошибками.
А по поводу того зачем мне это нужно я пока ничего не могу рассказать :( возможно позже, возможно GPL :)
«Это не баг, это фича»
Если Psi делает так, как написано в RFC, значит он этот RFC соблюдает. Получается, что разработчики других клиентов не соизволили вдумчиво дочитать RFC до конца.
Если Psi делает так, как написано в RFC, значит он этот RFC соблюдает. Получается, что разработчики других клиентов не соизволили вдумчиво дочитать RFC до конца.
А вы что — думаете RFC всегда описывает всё до конца? Там полно бывает прорех в подобных хитрых местах. Когда их обнаруживают, то выходят дополнения и исправления. Так, спецификация XML 1.0 существует аж в четырёх версиях. Если Psi соблюдает RFC, то вовсе не факт, что все остальные его не соблюдают!
Может проще заходить пользователям с разных ресурсов одного аккаунта в какую-нить конференцию и там разговаривать пиватно?
избавитесь от кучи проблем
избавитесь от кучи проблем
Спасибо за совет. Я его уже рассматривал. Конференции нужно создавать, а если нужно что бы пользователи обменялись парой сообщений и забыли об этом(а это нужно в моем случае) такой вариант не подходит. Да и к тому же некоторые клиенты не поддерживают инвайты в конференции защищенные паролем, а без этого приватная беседа может и не состояться.
Извеняюсь за долгое отсутсвие.
Может настроить автовход в конференцию — а ростер оставить пустым.
И использовать тот клиент который позволяет всё это провернуть «прозрачно» для пользователя
Может настроить автовход в конференцию — а ростер оставить пустым.
И использовать тот клиент который позволяет всё это провернуть «прозрачно» для пользователя
Если использовать тот клиент который позволяет провернуть все это прозрачно то появлеться ограничение на клиент. Если существует ограничение на клиенто то можно использовать только psi и оставить систему с одним jid'ом и разными ресурсами.
Автовход не понимаю как вы предлогаете осуществить. Цель позволить обменяться сообщениями пользователям с одного джида. то есть client@example.com/res1 напишет пару сообщений для client2@example.com и при этом client@example.com/res2 не должен иметь возможности их получить.
с конференциями я видел решение так:
client@example.org/res1 создает конференцию со случайным именем и защитой паролем. посылает инвайт client2@example.com и они в ней общаються. но конференцию нужно создавать а это будет ресурсоемко при большом количестве сессий.
Автовход не понимаю как вы предлогаете осуществить. Цель позволить обменяться сообщениями пользователям с одного джида. то есть client@example.com/res1 напишет пару сообщений для client2@example.com и при этом client@example.com/res2 не должен иметь возможности их получить.
с конференциями я видел решение так:
client@example.org/res1 создает конференцию со случайным именем и защитой паролем. посылает инвайт client2@example.com и они в ней общаються. но конференцию нужно создавать а это будет ресурсоемко при большом количестве сессий.
Попытался их установить.
Я.Онлайн работает только с яндексом и в контексте данного вопроса не актуален.
Digsby к счастью не заработал. 17 Мб инсталятор заставил зарегистрироваться(где?) и скомпилировал что то на C++ :) после установки поросил email и пароль. На ввод указанных при установе данных сказал что они не верные.
Если знаете как ими пользоваться то можете проверить было бы интересно посмотреть, я не осилил :)
Я.Онлайн работает только с яндексом и в контексте данного вопроса не актуален.
Digsby к счастью не заработал. 17 Мб инсталятор заставил зарегистрироваться(где?) и скомпилировал что то на C++ :) после установки поросил email и пароль. На ввод указанных при установе данных сказал что они не верные.
Если знаете как ими пользоваться то можете проверить было бы интересно посмотреть, я не осилил :)
> Я.Онлайн работает только с яндексом и в контексте данного вопроса не актуален.
Это не так. В данный момент я залогинен одновременно в GTalk, @ya.ru и @jabber.org из Я.Онлайна.
> 17 Мб инсталятор заставил зарегистрироваться(где?)
Регистрация на дигсби позволяет пользоваться одной парой email/пароль для аутентификации во всех сервисах.
> Если знаете как ими пользоваться то можете проверить
К сожалению, не владею методом проверки %)
Это не так. В данный момент я залогинен одновременно в GTalk, @ya.ru и @jabber.org из Я.Онлайна.
> 17 Мб инсталятор заставил зарегистрироваться(где?)
Регистрация на дигсби позволяет пользоваться одной парой email/пароль для аутентификации во всех сервисах.
> Если знаете как ими пользоваться то можете проверить
К сожалению, не владею методом проверки %)
Я.Онлайн предложил мне ввести адрес заканчивающийся на @yandex.ru и не предоставил альтернатив. Что я делаю не так?
а с дигсби сейчас ещё попробую, но те логин/пароль что указаны при регистрации он не принял…
а с дигсби сейчас ещё попробую, но те логин/пароль что указаны при регистрации он не принял…
Все таки Digsby не заработал. Попробывал даже пароль сбросить, но все равно говорит что неверные.
Возможно ему чем то не нравиться мое соединение с интернет?
Возможно ему чем то не нравиться мое соединение с интернет?
А для чего это нужно? :)
Если не секрет.
Как возможный обходной маневр можно повесить свой сервис с высоким приоритетом, который будет получать все сообщения без указанных res и пересылать с проставленым res обратно на сервер (клиентам разрешено общаться друг с другом в рамках своего логина).
Если не секрет.
Как возможный обходной маневр можно повесить свой сервис с высоким приоритетом, который будет получать все сообщения без указанных res и пересылать с проставленым res обратно на сервер (клиентам разрешено общаться друг с другом в рамках своего логина).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Возможности XMPP и Jabber клиенты