Комментарии 33
Я думаю что все дело в том что если клиенты не авторизованы — нет возможности определить находится ли определённый ресурс онлайн. По-этому Миранда считает что неизвестное состояние это оффлайн и отправляет сообщение на JID без ресурса. Насколько я понял RFC не описывает что нужно делать в ситуации когда не известно или ресурс онлайн или оффлайн. По-этому решение Миранды имеет смысл и не нарушает RFC. Хотя и Psi на самом деле не нарушает, так как данный аспект поведения не указан RFC.
+2
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 сообщении о отсутсвии?
+2
Тут нельзя однозначно прочитать. Так как изначально не было получено presence сообщение о присутствии, то можно сказать что по умолчанию ресурс не был доступен и соответсвенно the sender has knowledge (via presence) that the intended recipient's resource is no longer available.
Тут ведь не сказано что отправитель должен получить уведомленее о том что ресурс получателя недоступен, а только то что он должен принять решение на основе знаний об этом.
Тут ведь не сказано что отправитель должен получить уведомленее о том что ресурс получателя недоступен, а только то что он должен принять решение на основе знаний об этом.
+1
тут видимо дело в значении по умолчанию, как всегда :)
Мне не понятно почему miranda(да и другие клиенты) делают то что они делать не объязаны? если они не отрезают ресурс то с доставкой оффлайновых сообщений хорошо справиться сервер, благо это в рфц описано и ejabberd(на нем я тестировал) эти рекомендации соблюдает.
Мне не понятно почему miranda(да и другие клиенты) делают то что они делать не объязаны? если они не отрезают ресурс то с доставкой оффлайновых сообщений хорошо справиться сервер, благо это в рфц описано и ejabberd(на нем я тестировал) эти рекомендации соблюдает.
0
Ну опять же. 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 не дает даже рекомендаций. (По крайней мере исходя из тех цитат что вы привели здесь.)
0
вот как раз если бы было так как вы написали то это случай с psi. миранда же делает
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
имхо null != offline
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
имхо null != offline
0
Я описал работу как она по идее должна быть по RFC, подразумевая что такое сравнение должно быть во всех клиентах, включая и Миранду и Пси.
Потом я попробовал пояснить в чем разница в моем понимании:
> Тут вся проблема состоит в том, или считать неавторизованного отправителя Offline. Миранда считает, Пси — нет.
Смысл в том что на момент сравнения значение presence не определено, по этому все зависит от того как клиент обрабатывает неопределённое значение. Этого нет в RFC.
Потом я попробовал пояснить в чем разница в моем понимании:
> Тут вся проблема состоит в том, или считать неавторизованного отправителя Offline. Миранда считает, Пси — нет.
Смысл в том что на момент сравнения значение presence не определено, по этому все зависит от того как клиент обрабатывает неопределённое значение. Этого нет в RFC.
-1
ИМХО вы как раз описали работу psi, а у миранды обратная ситуация:
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
null != offline
if(presence == Online) {
отправить с ресурсом
} else {
отправить без ресурса
}
null != offline
-1
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.
Как видите, это вовсе не требование.
+1
Спасибо!
Довольно интересно, не совсем соответствует значению слова не применимо к RFC насколько я понимаю, ну да ладно :)
Тогда как я понимаю вообще нет проблемы в том плане что в клиентах (Миранде) баг реализации, так как рекомендацию можно выполнять, а можно и нет.
Довольно интересно, не совсем соответствует значению слова не применимо к RFC насколько я понимаю, ну да ладно :)
Тогда как я понимаю вообще нет проблемы в том плане что в клиентах (Миранде) баг реализации, так как рекомендацию можно выполнять, а можно и нет.
-1
SHOULD это конечно рекомендация. Но рекомендациям можно не следовать только если на то есть объективные причины. Я не вижу объективных причин отбрасывать ресурс при ответе на сообщение :) Забота о доставке сообщения отпадает потому как этим может заняться Jabber сервер. Есть какие либо другие серьезные причины что бы отвечать на JID без ресурса?
+1
Ну опять же. 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)
0
Миранда не запоминает ресурсы для оффлайновых контактов не из ростера, но для «нормальных» доступен как выбор непосредственно нужного ресурса, так и работа в режимах «Последний активный» и «На выбор сервера», что не во всех клиентах присутствует :)
Объясните, пожалуйста, хотя-бы в кратце зачем нужно столько хитростей? Не авторизованные, оффлайновые, да еще и с 1 джида? Возможно, мы что-нибудь придумаем :)
Объясните, пожалуйста, хотя-бы в кратце зачем нужно столько хитростей? Не авторизованные, оффлайновые, да еще и с 1 джида? Возможно, мы что-нибудь придумаем :)
+1
Спасибо, но эту часть задачи я пока решил без использования jabber :( Все эти хитрости не казались мне хитростями потому как я считаю протокол все их предусматривал и никаких недокументированных возможностей я не использовал :) Если бы jabber клиенты вели себя так как я ожидал то решение было довольно красивое…
+2
Жаль, что не получилось Вам помочь :)
+3
Все эти хитрости не казались мне хитростями потому как я считаю протокол все их предусматривал и никаких недокументированных возможностей я не использовал :)Хитрости — это то, чего 99% пользователей не использует. Неважно что написано в протоколе: если фича никем не используется, то она, скорее всего, не будет реализована. Или будет реализована с ошибками.
0
А по поводу того зачем мне это нужно я пока ничего не могу рассказать :( возможно позже, возможно GPL :)
+1
«Это не баг, это фича»
Если Psi делает так, как написано в RFC, значит он этот RFC соблюдает. Получается, что разработчики других клиентов не соизволили вдумчиво дочитать RFC до конца.
Если Psi делает так, как написано в RFC, значит он этот RFC соблюдает. Получается, что разработчики других клиентов не соизволили вдумчиво дочитать RFC до конца.
+2
А вы что — думаете RFC всегда описывает всё до конца? Там полно бывает прорех в подобных хитрых местах. Когда их обнаруживают, то выходят дополнения и исправления. Так, спецификация XML 1.0 существует аж в четырёх версиях. Если Psi соблюдает RFC, то вовсе не факт, что все остальные его не соблюдают!
0
Может проще заходить пользователям с разных ресурсов одного аккаунта в какую-нить конференцию и там разговаривать пиватно?
избавитесь от кучи проблем
избавитесь от кучи проблем
+3
Спасибо за совет. Я его уже рассматривал. Конференции нужно создавать, а если нужно что бы пользователи обменялись парой сообщений и забыли об этом(а это нужно в моем случае) такой вариант не подходит. Да и к тому же некоторые клиенты не поддерживают инвайты в конференции защищенные паролем, а без этого приватная беседа может и не состояться.
+1
Извеняюсь за долгое отсутсвие.
Может настроить автовход в конференцию — а ростер оставить пустым.
И использовать тот клиент который позволяет всё это провернуть «прозрачно» для пользователя
Может настроить автовход в конференцию — а ростер оставить пустым.
И использовать тот клиент который позволяет всё это провернуть «прозрачно» для пользователя
0
Если использовать тот клиент который позволяет провернуть все это прозрачно то появлеться ограничение на клиент. Если существует ограничение на клиенто то можно использовать только 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 и они в ней общаються. но конференцию нужно создавать а это будет ресурсоемко при большом количестве сессий.
0
Попытался их установить.
Я.Онлайн работает только с яндексом и в контексте данного вопроса не актуален.
Digsby к счастью не заработал. 17 Мб инсталятор заставил зарегистрироваться(где?) и скомпилировал что то на C++ :) после установки поросил email и пароль. На ввод указанных при установе данных сказал что они не верные.
Если знаете как ими пользоваться то можете проверить было бы интересно посмотреть, я не осилил :)
Я.Онлайн работает только с яндексом и в контексте данного вопроса не актуален.
Digsby к счастью не заработал. 17 Мб инсталятор заставил зарегистрироваться(где?) и скомпилировал что то на C++ :) после установки поросил email и пароль. На ввод указанных при установе данных сказал что они не верные.
Если знаете как ими пользоваться то можете проверить было бы интересно посмотреть, я не осилил :)
0
> Я.Онлайн работает только с яндексом и в контексте данного вопроса не актуален.
Это не так. В данный момент я залогинен одновременно в GTalk, @ya.ru и @jabber.org из Я.Онлайна.
> 17 Мб инсталятор заставил зарегистрироваться(где?)
Регистрация на дигсби позволяет пользоваться одной парой email/пароль для аутентификации во всех сервисах.
> Если знаете как ими пользоваться то можете проверить
К сожалению, не владею методом проверки %)
Это не так. В данный момент я залогинен одновременно в GTalk, @ya.ru и @jabber.org из Я.Онлайна.
> 17 Мб инсталятор заставил зарегистрироваться(где?)
Регистрация на дигсби позволяет пользоваться одной парой email/пароль для аутентификации во всех сервисах.
> Если знаете как ими пользоваться то можете проверить
К сожалению, не владею методом проверки %)
0
Я.Онлайн предложил мне ввести адрес заканчивающийся на @yandex.ru и не предоставил альтернатив. Что я делаю не так?
а с дигсби сейчас ещё попробую, но те логин/пароль что указаны при регистрации он не принял…
а с дигсби сейчас ещё попробую, но те логин/пароль что указаны при регистрации он не принял…
0
Для запуска Я.Онлайна требуется аккаунт на яндексе, да. Честно говоря, не вижу в этом проблемы. Однако после логина он будет работать с любым джаббером.
А с дигсби — что, даже не показывает контакт-лист и не дает добавить аккаунт?
А с дигсби — что, даже не показывает контакт-лист и не дает добавить аккаунт?
0
Все таки Digsby не заработал. Попробывал даже пароль сбросить, но все равно говорит что неверные.
Возможно ему чем то не нравиться мое соединение с интернет?
Возможно ему чем то не нравиться мое соединение с интернет?
0
А для чего это нужно? :)
Если не секрет.
Как возможный обходной маневр можно повесить свой сервис с высоким приоритетом, который будет получать все сообщения без указанных res и пересылать с проставленым res обратно на сервер (клиентам разрешено общаться друг с другом в рамках своего логина).
Если не секрет.
Как возможный обходной маневр можно повесить свой сервис с высоким приоритетом, который будет получать все сообщения без указанных res и пересылать с проставленым res обратно на сервер (клиентам разрешено общаться друг с другом в рамках своего логина).
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Возможности XMPP и Jabber клиенты