Обсуждение:Недостатки Jabber

слова о существовании трёх несовместимых "способов" передачи файлов, звучит как кривизна протокола.

лучше сместить акцент к клиентам, не поддерживающих эти jep'ы или заменить "и не все эти способы поддерживаются всеми клиентами Jabber." на логически верное. // mag2000 2008.08.30 16:37

fixed

решающим фактором отсутствие большого выбора софта на мобилу не является запускайте ssh на своих девайсах и радуйтесь mcabber'у, а для остальных есть бомбус //mag2000 2008.08.30 16:37

Перенесено из главной: Сложность настройки ICQ-транспорта. Многие из них либо не стабильны, либо не работают. Те что работают могут не распознать имена ICQ контактов и их придется переименовывать вручную, а так же сортировать по группам. // 83.149.32.112

Не согласен. Это не является недостатком Jabber'a, как такового. Напомню, что транспорт - лишь фича, возможность, позволяющая общаться с людьми из других сетей. К примеру, я не пользуюсь подобными транспортами, а кто-то пользуется, предположим, прекрасно работающим MRIM-транспортом. Является ли для меня или того человека нестабильность отдельно взятого ICQ-транспорта недостатком Jabber-сети? Сомневаюсь.

Добавлю, в некоторые сети и сервисы, к примеру, вообще не существует транспортов. Считать ли это недостатком сети? Нет, это просто нереализованная возможность.

1 - насчет сложности. Пробраузить сервисы -> Выбрать ICQ-транспорт -> Нажать "Зарегистрироваться" -> Ввести данные. По-моему, это несложно, тем более для каждого клиента есть описание в картинках по работе с транспортами, а тот же Spark, например, вообще автоматом добавляет уникальные транспорты в закладки, все, что требуется - просто нажать на иконке протокола в закладках.

2 - для обсуждения стабильности ICQ-транспортов есть специальная страница, где можно сделать пометку касательно работоспособности того или иного транспорта.

3 - возможно, они и работают, но пока отобраны не все публичные. Иными словами, в том списке не все транспорты могут позволять регистрацию с других серверов, что не делает их неработоспособными. Благодаря обсуждениям и статистике со временем в списке останутся только лишь публичные транспорты.

4 - насчет распознавания имен. Насколько знаю, есть JIT, есть PyICQ-транспорт. Какой-то из них устаревший и не резолвит имена, возможно попадался именно он. --rain 14:25, 18 ноября 2008 (UTC)

Есть еще и OpenFire. Устаревший - это JIT. Имена не резолвит ни первый, ни второй, ни третий, насколько понимаю я. --ulidtko 01:18, 14 марта 2009 (UTC)

Openfire'овский ресолвит, плюс раскладывает на группы. У остальных ресолвинг на стороне клиента, а раскладывать вообще никак нельзя, только ручками, по некоторым причинам, не зависящим от транспорта. H31 14:48, 14 марта 2009 (UTC)

Сложность настройки ICQ-транспорта.
Сложность преувеличена. Подтверждение: девушка-бухгалтер сумела по подсказкам, пересылаемым через jabber, зарегистрироваться на транспорте.

И не одна. Сложность сильно преувеличена. --ulidtko 01:18, 14 марта 2009 (UTC)

Многие из них либо не стабильны, либо не работают
У альтернативных клиентов ICQ те же проблемы.

могут не распознать имена ICQ контактов и их придется переименовывать вручную
RTFM! Через ad-hoc даёшь транспорту команду отресолвить ники.

-- Grumbler 01:28, 13 февраля 2009 (UTC)

Не надо здесь бросаться rtfm'ами. Ники резолвятся не по ад-хоку, а контекстным меню клиента. Резолвить ники - это его фича. --ulidtko 01:18, 14 марта 2009 (UTC)

Гарантированная доставка сообщенияПравить

В Jabber(или на некоторых серверах) нет функции для гарантийной доставки сообщения. К примеру сижу я на мобиле, заехал в метро, мобилу выключил, сервер почему-то долгое время считает что я online, и все сообщения, которые были отправлены мне теряются. Сервером пользуюсь: jabber.ru, не знаю кто виноват, то ли протокол не предусматривает подтвержения доставки сообщения, то ли на сервере не установлены параметры типа "не удалять сообщения, пока не пришло уведомление о том, что они были доставлены". ASM 21:39, 19 апреля 2009 (UTC)

Кстати, вопрос интересный, функция (если ее еще нет) была бы полезной, да и реализовывается на первый взгляд несложно (по-большому счету, все изменения делаются на стороне сервера, но, с другой стороны, клиенты тоже должны поддерживать уведомление о доставке, а это еще не везде реализовано). Если немного поразмышлять, то

Уведомление о доставке сообщений между клиентами сейчас есть, т.е., клиент получает сообщение, формирует iq-пакет отправителю, тот его получает и сигнализирует об удачной доставке.
Серверу, насколько понимаю, данный пакет безразличен, он просто передает его по назначению.
Можно сделать контроль факта пересылки данного пакета (т.е., если клиент сформировал такой пакет - значит, сообщение дошло и на сервере его можно удалять), но возникают подпункты:
- не все клиенты поддерживают уведомление о доставке, следовательно, не везде эта схема будет работать
- клиент по какой-то причине не сформировал пакет / он не дошел даже до сервера, но есть некий промежуток времени, пока клиент считается подключенным к серверу (на jabber.ru, насколько слышал, этот промежуток увеличен как раз именно из-за мобилочников - чтобы их не отключало постоянно при обрывах связи и клиент мог прозрачно переподключиться (пример, в это время у меня оборвалась связь, но комнаты я не покидал и сообщения не потеряны, аналогично и при прямом общении); делает ли это клиент - это уже другой вопрос), так вот, как опознать, что надо еще раз отправить сообщение? Периодически отправлять? А если нарушение связи только на исходящем канале у пользователя - клиент будет получать дубликаты сообщений. По факту переподключения? Тогда сообщения так же само теряются. Более частая проверка связи? Увеличение трафика, частые дисконнекты при плохой связи.

В общем, вопрос интересный и это, скорее, на JRD, там он как-то ближе, может что и подскажут :). Ну и это, скорее, не обсуждение "Недостатков Jabber", а wishlist, то, что хотелось бы видеть среди функций сети, так как отследить все варианты обрывов связи сложно и в других сетях с этим тоже не все гладко.--rain 23:31, 19 апреля 2009 (UTC)

В ICQ именно так и сделано. Клиент считает сообщение доставленным в том случае, если оно дошло до сервера, дальнейшая его судьба его не беспокоит. В Jabber подобное поведение (плюс если один из клиентов не отвечает - переслать ему позже, как только выйдет на связь) реализуется через один из XEPов, но пока что он не реализован в ejabberd (хотя потихоньку намечается). Сейчас же используется client-side уведомления, как выше сказал ув. rain. На мой взгляд, это гораздо удобнее. Если сообщение не дошло - можно ещё раз подумать, не написал ли ты дурость и бред :) . В Миранде это вообще очень удобно сделано: чтобы переслать, нужно просто нажать кнопочку. H31 09:21, 20 апреля 2009 (UTC)

СпамПравить

Прощу заметить, что на данный момент в Jabber защиты от спама нет, правда и спама самого тоже нет, но как только jabber начнёт пользоваться большой популярностью, то появится очень много коварных ботов, которые будут спамить. Причём в ICQ, как централизованной системе, с этим как-то можно бороться, а в jabber, децентрализованной, бороться очень сложно. Боюсь может получиться также, как сейчас происходит с email спамом. ASM 21:52, 19 апреля 2009 (UTC)

Не совсем так.

Во-первых, каким образом централизованная система лучше приспособлена для борьбы со спамом, чем распределенная? В плане адресации даже лучше - двухмерная адресация пользователя в Jabber с большим числом вариантов имени пользователя (используются буквы, цифры, спецсимволы, а также возможно использование национальных символов) и домена (тысячи вариантов имен) против одномерной цифровой в той же ICQ, где куда ни ткни - вероятный пользователь и спам-листы можно составлять простейшим скриптом.
см. тут
В клиенте, по-большому счету, можно реализовывать что угодно и это уже не касается какой-то определенной сети.
http://xmpp.org/extensions/xep-0158.html

--rain 23:51, 19 апреля 2009 (UTC)

Известный миф. См. тут. H31 09:21, 20 апреля 2009 (UTC)