| Текущая версия |
Ваш текст |
| Строка 9: |
Строка 9: |
| Перенесено из главной: Сложность настройки ICQ-транспорта. Многие из них либо не стабильны, либо не работают. Те что работают могут не распознать имена ICQ контактов и их придется переименовывать вручную, а так же сортировать по группам. // 83.149.32.112 | | Перенесено из главной: Сложность настройки ICQ-транспорта. Многие из них либо не стабильны, либо не работают. Те что работают могут не распознать имена ICQ контактов и их придется переименовывать вручную, а так же сортировать по группам. // 83.149.32.112 |
| :: Не согласен. Это не является недостатком Jabber'a, как такового. Напомню, что транспорт - лишь фича, возможность, позволяющая общаться с людьми из других сетей. К примеру, я не пользуюсь подобными транспортами, а кто-то пользуется, предположим, прекрасно работающим MRIM-транспортом. Является ли для меня или того человека нестабильность отдельно взятого ICQ-транспорта недостатком Jabber-сети? Сомневаюсь. | | :: Не согласен. Это не является недостатком Jabber'a, как такового. Напомню, что транспорт - лишь фича, возможность, позволяющая общаться с людьми из других сетей. К примеру, я не пользуюсь подобными транспортами, а кто-то пользуется, предположим, прекрасно работающим MRIM-транспортом. Является ли для меня или того человека нестабильность отдельно взятого ICQ-транспорта недостатком Jabber-сети? Сомневаюсь. |
| :: Добавлю, в некоторые сети и сервисы, к примеру, вообще не существует транспортов. Считать ли это недостатком сети? Нет, это просто нереализованная возможность.
| |
| :: 1 - насчет сложности. Пробраузить сервисы -> Выбрать ICQ-транспорт -> Нажать "Зарегистрироваться" -> Ввести данные. По-моему, это несложно, тем более для каждого клиента есть описание в картинках по работе с транспортами, а тот же [[Spark]], например, вообще автоматом добавляет уникальные транспорты в закладки, все, что требуется - просто нажать на иконке протокола в закладках. | | :: 1 - насчет сложности. Пробраузить сервисы -> Выбрать ICQ-транспорт -> Нажать "Зарегистрироваться" -> Ввести данные. По-моему, это несложно, тем более для каждого клиента есть описание в картинках по работе с транспортами, а тот же [[Spark]], например, вообще автоматом добавляет уникальные транспорты в закладки, все, что требуется - просто нажать на иконке протокола в закладках. |
| :: 2 - для обсуждения стабильности ICQ-транспортов есть специальная страница, где можно сделать пометку касательно работоспособности того или иного транспорта. | | :: 2 - для обсуждения стабильности ICQ-транспортов есть специальная страница, где можно сделать пометку касательно работоспособности того или иного транспорта. |
| :: 3 - возможно, они и работают, но пока отобраны не все публичные. Иными словами, в том списке не все транспорты могут позволять регистрацию с других серверов, что не делает их неработоспособными. Благодаря обсуждениям и статистике со временем в списке останутся только лишь публичные транспорты. | | :: 3 - возможно, они и работают, но пока отобраны не все публичные. Иными словами, в том списке не все транспорты могут позволять регистрацию с других серверов, что не делает их неработоспособными. Благодаря обсуждениям и статистике со временем в списке останутся только лишь публичные транспорты. |
| :: 4 - насчет распознавания имен. Насколько знаю, есть JIT, есть PyICQ-транспорт. Какой-то из них устаревший и не резолвит имена, возможно попадался именно он. --[[Участник:Rain|rain]] 14:25, 18 ноября 2008 (UTC) | | :: 4 - насчет распознавания имен. Насколько знаю, есть JIT, есть PyICQ-транспорт. Какой-то из них устаревший и не резолвит имена, возможно попадался именно он. --[[Участник:Rain|rain]] 14:25, 18 ноября 2008 (UTC) |
| ::: Есть еще и OpenFire. Устаревший - это JIT. Имена не резолвит ни первый, ни второй, ни третий, насколько понимаю я. --ulidtko 01:18, 14 марта 2009 (UTC)
| |
| :::: Openfire'овский ресолвит, плюс раскладывает на группы. У остальных ресолвинг на стороне клиента, а раскладывать вообще никак нельзя, только ручками, по некоторым причинам, не зависящим от транспорта. [[Участник:H31|H31]] 14:48, 14 марта 2009 (UTC)
| |
| <br>
| |
| :: ''Сложность настройки ICQ-транспорта.''<br>Сложность преувеличена. Подтверждение: девушка-бухгалтер сумела по подсказкам, пересылаемым через jabber, зарегистрироваться на транспорте.
| |
| ::: И не одна. Сложность сильно преувеличена. --ulidtko 01:18, 14 марта 2009 (UTC)
| |
| :: ''Многие из них либо не стабильны, либо не работают''<br>У альтернативных клиентов ICQ те же проблемы.
| |
| :: ''могут не распознать имена ICQ контактов и их придется переименовывать вручную''<br>RTFM! Через ad-hoc даёшь транспорту команду отресолвить ники.
| |
| :: -- [[Участник:Grumbler|Grumbler]] 01:28, 13 февраля 2009 (UTC)
| |
| ::: Не надо здесь бросаться rtfm'ами. Ники резолвятся не по ад-хоку, а контекстным меню клиента. Резолвить ники - это его фича. --ulidtko 01:18, 14 марта 2009 (UTC)
| |
|
| |
| == Гарантированная доставка сообщения ==
| |
|
| |
| В Jabber(или на некоторых серверах) нет функции для гарантийной доставки сообщения. К примеру сижу я на мобиле, заехал в метро, мобилу выключил, сервер почему-то долгое время считает что я online, и все сообщения, которые были отправлены мне теряются. Сервером пользуюсь: jabber.ru, не знаю кто виноват, то ли протокол не предусматривает подтвержения доставки сообщения, то ли на сервере не установлены параметры типа "не удалять сообщения, пока не пришло уведомление о том, что они были доставлены". [[Участник:ASM|ASM]] 21:39, 19 апреля 2009 (UTC)
| |
| : Кстати, вопрос интересный, функция (если ее еще нет) была бы полезной, да и реализовывается на первый взгляд несложно (по-большому счету, все изменения делаются на стороне сервера, но, с другой стороны, клиенты тоже должны поддерживать уведомление о доставке, а это еще не везде реализовано). Если немного поразмышлять, то
| |
| * Уведомление о доставке сообщений между клиентами сейчас есть, т.е., клиент получает сообщение, формирует iq-пакет отправителю, тот его получает и сигнализирует об удачной доставке.
| |
| * Серверу, насколько понимаю, данный пакет безразличен, он просто передает его по назначению.
| |
| * Можно сделать контроль факта пересылки данного пакета (т.е., если клиент сформировал такой пакет - значит, сообщение дошло и на сервере его можно удалять), но возникают подпункты:
| |
| ** не все клиенты поддерживают уведомление о доставке, следовательно, не везде эта схема будет работать
| |
| ** клиент по какой-то причине не сформировал пакет / он не дошел даже до сервера, но есть некий промежуток времени, пока клиент считается подключенным к серверу (на jabber.ru, насколько слышал, этот промежуток увеличен как раз именно из-за мобилочников - чтобы их не отключало постоянно при обрывах связи и клиент мог прозрачно переподключиться ([http://chatlogs.jabbus.org/muc/linuxoid@conference.jabbus.org/2009/04/19.html#15:03:35.981951 пример], в это время у меня оборвалась связь, но комнаты я не покидал и сообщения не потеряны, аналогично и при прямом общении); делает ли это клиент - это уже другой вопрос), так вот, как опознать, что надо еще раз отправить сообщение? Периодически отправлять? А если нарушение связи только на исходящем канале у пользователя - клиент будет получать дубликаты сообщений. По факту переподключения? Тогда сообщения так же само теряются. Более частая проверка связи? Увеличение трафика, частые дисконнекты при плохой связи.
| |
| : В общем, вопрос интересный и это, скорее, на [[JRD:|JRD]], там он как-то ближе, может что и подскажут :). Ну и это, скорее, не обсуждение "Недостатков Jabber", а wishlist, то, что хотелось бы видеть среди функций сети, так как отследить все варианты обрывов связи сложно и в других сетях с этим тоже не все гладко.--[[Участник:Rain|rain]] 23:31, 19 апреля 2009 (UTC)
| |
|
| |
| : В ICQ именно так и сделано. Клиент считает сообщение доставленным в том случае, если оно дошло до сервера, дальнейшая его судьба его не беспокоит. В Jabber подобное поведение (плюс если один из клиентов не отвечает - переслать ему позже, как только выйдет на связь) реализуется через один из XEPов, но пока что он не реализован в ejabberd (хотя потихоньку намечается). Сейчас же используется client-side уведомления, как выше сказал ув. [[Участник:Rain|rain]]. На мой взгляд, это гораздо удобнее. Если сообщение не дошло - можно ещё раз подумать, не написал ли ты дурость и бред :) . В Миранде это вообще очень удобно сделано: чтобы переслать, нужно просто нажать кнопочку. [[Участник:H31|H31]] 09:21, 20 апреля 2009 (UTC)
| |
|
| |
| == Спам ==
| |
|
| |
| Прощу заметить, что на данный момент в Jabber защиты от спама нет, правда и спама самого тоже нет, но как только jabber начнёт пользоваться большой популярностью, то появится очень много коварных ботов, которые будут спамить. Причём в ICQ, как централизованной системе, с этим как-то можно бороться, а в jabber, децентрализованной, бороться очень сложно. Боюсь может получиться также, как сейчас происходит с email спамом. [[Участник:ASM|ASM]] 21:52, 19 апреля 2009 (UTC)
| |
| : Не совсем так.
| |
| * Во-первых, каким образом централизованная система лучше приспособлена для борьбы со спамом, чем распределенная? В плане адресации даже лучше - двухмерная адресация пользователя в Jabber с большим числом вариантов имени пользователя (используются буквы, цифры, спецсимволы, а также возможно использование национальных символов) и домена (тысячи вариантов имен) против одномерной цифровой в той же ICQ, где [http://www.icq.com/people/about_me.php?uin=123456789 куда ни ткни] - вероятный пользователь и спам-листы можно составлять простейшим скриптом.
| |
| * [[Списки приватности|см. тут]]
| |
| * В клиенте, по-большому счету, можно реализовывать что угодно и это уже не касается какой-то определенной сети.
| |
| * http://xmpp.org/extensions/xep-0158.html
| |
| : --[[Участник:Rain|rain]] 23:51, 19 апреля 2009 (UTC)
| |
|
| |
| : Известный миф. [[Jabber FAQ: Ответы на вопросы#?: Часто слышу, что в Jabber защищен от спама, однако e-mail тоже не имеет единого сервера, что не мешает рассылать спам. Более того, в Jabber есть поиск, он может помочь спамеру.|См. тут]]. [[Участник:H31|H31]] 09:21, 20 апреля 2009 (UTC)
| |
