Комментарии 261
вот она революция)
НЛО прилетело и опубликовало эту надпись здесь
По поводу алгоритма отправки сообщений не очень понятно. Лично мне удобно в скайпе. Полный дубль истории, видно как отправляются сообщения на соседнем клиенте. Это как плюс, так и минус. Было бы очень классно при общении с контактами указывать, будет ли синхронизирована история в реальном времени.
Отписал свой UIN в личку.
Отписал свой UIN в личку.
Опишу ситуацию, которая меня не устраивает в данный момент. Я постоянно держу включенным клиент на ноутбуке. Вот нужно мне куда то срочно отойти. Первое, что я делаю — выключаю аську на ноутбуке, читаю сообщения, которые мне пришли (а ведь закон подлости, они приходят пачками именно в тот момент, когда мне нужно отойти). Далее я закрываю клиент и запускаю на телефоне, отвечаю уже там.
Теперь я вернулся, телефон лежит в кармане, про аську я совсем забыл. Устройства начинают бороться за коннект, пока мне не сообщат, что лимит попыток переподключения исчерпан. Обидно.
Лично меня не устроит способ, предложенный в (http://habrahabr.ru/company/mailru/blog/128777/#comment_4260407)
Теперь я вернулся, телефон лежит в кармане, про аську я совсем забыл. Устройства начинают бороться за коннект, пока мне не сообщат, что лимит попыток переподключения исчерпан. Обидно.
Лично меня не устроит способ, предложенный в (http://habrahabr.ru/company/mailru/blog/128777/#comment_4260407)
Все работает. Замечены 2 странности.
Сам mail.ru агент не позволяет зайти одновременно с двух устройств. Я раньше не пользовался им, может что то не знаю.
Синхронизируются только входящие сообщения. Я не вижу, что пишу с телефона на компе и наоборот.
В данный момент лично для меня есть сильный аргумент для удаления qip везде, где он использовался и установки агента. Даже без синхронизации исходящих сообщений.
Теперь вопрос безопасности. Вы подключаетесь к моей учетной записи от своего сервера и транслируете сообщения на мои несколько подключенных клиентов? Как вы храните мой пароль?
Сам mail.ru агент не позволяет зайти одновременно с двух устройств. Я раньше не пользовался им, может что то не знаю.
Синхронизируются только входящие сообщения. Я не вижу, что пишу с телефона на компе и наоборот.
В данный момент лично для меня есть сильный аргумент для удаления qip везде, где он использовался и установки агента. Даже без синхронизации исходящих сообщений.
Теперь вопрос безопасности. Вы подключаетесь к моей учетной записи от своего сервера и транслируете сообщения на мои несколько подключенных клиентов? Как вы храните мой пароль?
Мне кажется, отсылать нужно на источники последней активности. Ушел человек на перерыв, взял с собой телефон с ICQ, переписывается фривольными сообщениями — а у него все они всплывают на рабочем компьютере… Нехорошо. Сообщения должны доставляться туда, где сейчас находится человек.
Плохо, ушли Вы на обед, взяли с собой мобильный, а последняя активность была на компьютере и пока Вы с мобильного что-нибудь не отправите все сообщения будут идти на компьютер, что не удобно
Хотите сказать, вы берете телефон и не нажимаете на нём ни одной кнопки — посмотреть время, проверить, нет ли новых сообщений (вдруг не услышал), проверить заряд батареи etc? Или это я один такой?)
Не думаю, что все мобильные устройства позволят перехватывать события. Сложность с определением активности, признайтесь же =)
Он просто лежит в кармане, почему для того чтобы мне приходили сообщения я должен его тормошить? Это неудобно. Приложение же следящее за чужой активностью мне моя паранойя поставить не позволит. Мало ли, что оно потом с этими данными делает
Я сижу за компом, мне пришла смска — читаю её и в этот момент на комп сообщения не приходят.
А если статус «Отошел» тогда не отсылать?
Т.е. только для активных?
Т.е. только для активных?
Статусы как активность интерпретироваться не должны. Например, я могу быть за компом, но при этом я заниматься каким-либо делом, при этом не настолько важным чтобы ставить статус «Небеспокоить», в таком случае логично поставить статус «отошел» чтобы люди видели, что ответить я могу не сразу.
Имхо ненужно изобретать велосипед. Есть два подхода:
1. Подход скайпа. Синхронизировать история за поределенный период
2. Подход XMPP. Сообщение рассылаются устройствам с наибольшим приоритетом
Оба подхода работают прозрачно для пользователя. Всякая эвристика рассчитанная на определение последней активности непрозрачна для пользователя, а значит будет приводить к потере сообщений.
Имхо ненужно изобретать велосипед. Есть два подхода:
1. Подход скайпа. Синхронизировать история за поределенный период
2. Подход XMPP. Сообщение рассылаются устройствам с наибольшим приоритетом
Оба подхода работают прозрачно для пользователя. Всякая эвристика рассчитанная на определение последней активности непрозрачна для пользователя, а значит будет приводить к потере сообщений.
3. Ленивая (по требованию) синхронизация (вплоть до полной) с глобальным флагом прочитанности сообщения. То есть с любого клиента (девайса) можно загрузить всё, что нужно и точно знать, какие сообщения прочитаны, а какие нет (в том числе и для того, чтобы знать что грузить, а что нет).
Лучше тогда промежуток времени от последнего полоченного сообщения от клиента задавать. То есть по умолчанию грузится последние сообщение +, например, все которые были получены за 24 часа до него. Промежуток задавать в настройках
Последнее сообщение от контакта получено 10 лет назад — оно мне нужно?
Идея синхронизации как в скайпе хороша, но имхо, не раньше, чем другой источник проявит активность.
И еще, почему бы не предоставить выбор пользователю? Сделать в настройках клиента radio-button, типа:
«когда я активен на этом клиенте:
-рассылать всем остальным подключенным;
-синхронизировать историю при потере активности;
-не синхронизировать с другими устройствами»
И на каждом клиенте можно свои настройки задать. Получается вполне гибко, и пользователь доволен, и у вас вопросов не возникает.
И еще, почему бы не предоставить выбор пользователю? Сделать в настройках клиента radio-button, типа:
«когда я активен на этом клиенте:
-рассылать всем остальным подключенным;
-синхронизировать историю при потере активности;
-не синхронизировать с другими устройствами»
И на каждом клиенте можно свои настройки задать. Получается вполне гибко, и пользователь доволен, и у вас вопросов не возникает.
А нефик фривольные сообщения с рабочей аськи писать. Надо разделять личные и рабочие дела.
Согласен с большинством — мне по душе подход скайпа. History на всех устройствах должны быть идентичны.
Согласен с большинством — мне по душе подход скайпа. History на всех устройствах должны быть идентичны.
В скайпе далеко не идеальный подход. По крайней мере, сервер присылает клиенту историю как начавшийся диалог.
На ноуте скайп включен редко. На десктопе — всегда. Стоит включить скайп на ноуте и туда начинает приходить толпа сообщений как будто мне кто-то пишет. Разгребать это очень неприятно.
Если они допилят клиент-сервер так, чтобы это воспринималось как история, а не входящее сообщение, то будет ок.
На ноуте скайп включен редко. На десктопе — всегда. Стоит включить скайп на ноуте и туда начинает приходить толпа сообщений как будто мне кто-то пишет. Разгребать это очень неприятно.
Если они допилят клиент-сервер так, чтобы это воспринималось как история, а не входящее сообщение, то будет ок.
Это да — не очень удобно, но ради синхры базы можно пережить. Это лучше чем перебирать все свои клиенты в поисках типа «блин на какую из асек мне скидывали ip сервера».
Это надо не переживать, а решить эту проблему в конце концов.
А я через дропбокс все синхронизирую
В принципе рабочий вариант, если аська не запущена одновременно на ББ и смарте. Если по очереди юзать, то да — вполне нормуль. Но я аську на работе вообще не вырубаю, так что мне такой вариант не подойдет :(
Хотя в моем случае вариант с дропбоксом все равно не пройдет. На работе миранда под вайном (ну привык я к ней....). На смарте ее база не откроется ни одним из клиентов. Так что пока живу без аськи на смарте, т.к. забодался искать что куда писали. Поэтому гоняю на смарте скайп. Если я кому-то срочно нужен, то он достанет меня и через скайп, а если не сможет — значит не особо сильно я и нужен в данный момент — потерпит пока я за ББ появлюсь (админам тоже иногда надо отдыхать).
В принципе все что надо добавить в протоколе — при прочтении сообщения на сервер должен уходить флажок «сообщение прочитано». Соответственно при получении сообщений на другом устройстве при наличии такого флажка, можно было бы просто молча писать их в базу.
Дык не обязательно всплывать сообщениям на экран — пусть себе мигают в трее.
Скайп доставляет сразу всем подключенным клиентам — помоему это правильно. Например, полезно когда хистори везде сохраняется.
А звон приходящего сообщения сразу в двух местах не раздражает?
я вообще отключаю звук во всех мессенджерах сразу после установки, так что нет, не раздражает )
Разве это стоит отсутствия синхронизации? Попробуйте одном месте выключить звук.
Не раздражает. Мало того, что скайп доставляет сообщение всем подключенным клиентам, он ещё додоставляет вновь включенному клиенту сообщения, которые были посланы, пока он был отключен. И это офигенно удобно, потому что история сообщений в результате на всех клиентах синхронизирована. Послали тебе на телефонный скайп ссылку — пришел домой, удобно и с компа её посмотреть, а не париться, вбивая вручную. Или проконсультироваться с историей переписки, проведенной на компе, позже на телефоне (например, адрес там какой-нить уточнить).
Так что совершенно правильно и корректно сделать так же, как делает скайп. Всё остальное — это будет ужасно, только история фрагментируется и потеряет смысл.
Так что совершенно правильно и корректно сделать так же, как делает скайп. Всё остальное — это будет ужасно, только история фрагментируется и потеряет смысл.
Ну а если я неделю (месяц, год) общаюсь с компьютера, потом решу зайти с мобильного, зачем мне получать километры оффлайн сообщений? Это и большой трафик, и icq клиент просто не выдержит.
Предусмотреть возможность отключения получения «километров сообщений»? При входе клиент спрашивает «100500 сообщений на этот UIN нет локально, непрочитано 2. Загрузить все или загрузить только новые?»
А если сообщения от 100 контактов?
Идея синхронизации, с точки зрения большинства мобильных устройств, — утопия
Идея синхронизации, с точки зрения большинства мобильных устройств, — утопия
Если расширить идею, то нужно реализовать ленивую загрузку сообщений. Но вот почему утопия — я не понимаю. Объёмы карт памяти измеряются гигабайтами, встроенной — сотнями мегабайт. Мало?
Решается кнопкой для мобильного клиента «Синхронизировать историю только по wi-fi» для всех контактов, еще кнопку в меню контакта «Синхронизировать историю этого контакта» для синхронизации истории конкретного контакта. А последние, допустим, 10 (можно задать вручную) непрочитанных сообщений пусть приходят на мобильный. Прочитано/не прочитано пусть определяется отсылкой пакета на сервер.
а не проще синхронизировать сразу последние 10 сообщений [активного контакта], а в фоне загружать что угодно
Нет смысла для последних 10 сообщений, обычно прочитанные сообщения необходимы лишь чтоб вспомнить на чем остановилась беседа, достаточно трех, всё остальное можно повесить на пункт в меню для загрузки вручную, это актуально для мобильного интернета с лимитированным трафиком (для тех у кого безлимитный мобильный интернет, отключается пунктом в меню «Синхронизировать историю только по wi-fi»), по вафле, как я уже говорил пусть всё синхронизируется в фоне.
незнаю незнаю
я заметил что последнее время люди не пишут абзацами
они пишут короткими фразами
типа вот так
этому способствует отправка по ентеру
я заметил что последнее время люди не пишут абзацами
они пишут короткими фразами
типа вот так
этому способствует отправка по ентеру
они пишут короткими фразами
типа вот так
этому способствует отправка по ентеру
мне достаточно этих трёх сообщений чтоб вспомнить о чем мы с Вами говорили
а Вам?
типа вот так
этому способствует отправка по ентеру
мне достаточно этих трёх сообщений чтоб вспомнить о чем мы с Вами говорили
а Вам?
боже мой. а так:
напоминаю что отправить документ в этот раз нужно на мой личный имейл
123@123.12
вы поняли?
— да
тогда до связи
всего хорошего
и вам не хварать
— Удачи вам вспомнить мыло
напоминаю что отправить документ в этот раз нужно на мой личный имейл
123@123.12
вы поняли?
— да
тогда до связи
всего хорошего
и вам не хварать
— Удачи вам вспомнить мыло
Таких идиотов кто будет переспрашивать понял ли я, потом еще распинаться в любезностях по полгода довольно мало, эта беседа выдумана, а даже если и нет, то бывает довольно редко, а когда бывает всегда можно подгрузить историю вручную, тем более документ вы скорее всего будете отправлять через нормальный интернет — на работе или у себя дома, там где есть вафля, да и вообще нет необходимости с нормальным интернетом смотреть в аську на мобильном. Мы тут говорили именно про мобильную версию и исключительно в целях экономии пропускной способности канала и экономии денег на трафик, на настольном клиенте путь синхронизируется вся история.
Да даже если так случится что нужно отправить документ:
1. С мобильного телефона
2. С мобильным интернетом
То я ни за что не забуду, что мне нужно отправить документ после того как я сказал, что я понял, а узнать емэйл можно простой ручной синхронизацией, которую можно в любой момент остановить специальной кнопкой. Т.е. сообщения будут загружаться блоками от самого последнего до самого первого.
Да даже если так случится что нужно отправить документ:
1. С мобильного телефона
2. С мобильным интернетом
То я ни за что не забуду, что мне нужно отправить документ после того как я сказал, что я понял, а узнать емэйл можно простой ручной синхронизацией, которую можно в любой момент остановить специальной кнопкой. Т.е. сообщения будут загружаться блоками от самого последнего до самого первого.
Дайте ка подумать… сохранить хорошие отношения с человеком и нормально сделать свою работу или сэкономить трафик и три рубля… сложный быбор то какой.
1. Если у вас безлимитный мобильный интернет, то тут вообще не о чем говорить — снимаете галку «Синхронизировать историю только по wi-fi» и у вас история синхронизируется на мобильном устройстве автоматически всегда.
2. Мы сейчас говорим об обычных пользователях, а не о наших с Вами потребностях, у большинства из них не безлимитный интернет и не так много людей используют ICQ на МОБИЛЬНОМ ТЕЛЕФОНЕ для работы.
И обычные пользователи (а их подавляющее большинство) просто «болтают в аське», всё что им нужно, это не переспрашивать о чем они говорили с контактом час-день-неделю назад и неожиданно прервали беседу.
2. Мы сейчас говорим об обычных пользователях, а не о наших с Вами потребностях, у большинства из них не безлимитный интернет и не так много людей используют ICQ на МОБИЛЬНОМ ТЕЛЕФОНЕ для работы.
И обычные пользователи (а их подавляющее большинство) просто «болтают в аське», всё что им нужно, это не переспрашивать о чем они говорили с контактом час-день-неделю назад и неожиданно прервали беседу.
А нам надо будет рыскать по всем девайсам где же был IP, телефон, адрес, дата.
Либо извращаться и цитировать сообщение самому себе (а на сотке это очень неудобно).
Либо извращаться и цитировать сообщение самому себе (а на сотке это очень неудобно).
Простите, но я Вас не понял, поясните.
Получил телефонный номер, по которому надо будет позвенеть.
Или любой другой факт.
Позже вспомнил, что разговор и с компа, и со смартофона. С компа либо через веб-интерфейс, либо с толстого клиента. К тому же у тебя на человека несколько контактов — ICQ, Jabber, MRIM.
Вот и начинаешь сидеть и листать все истории.
Либо по получении факта приходится его пересылать на один условленный контакт, например, если считаете для себя основным XMPP. С надеждой, что остальные девайсы это сообщение самого себе подхватится.
Особенно мерзко получить длинный урл на сотку (особенно Quoted Printable) и пытаться его набрать на компе.
Или любой другой факт.
Позже вспомнил, что разговор и с компа, и со смартофона. С компа либо через веб-интерфейс, либо с толстого клиента. К тому же у тебя на человека несколько контактов — ICQ, Jabber, MRIM.
Вот и начинаешь сидеть и листать все истории.
Либо по получении факта приходится его пересылать на один условленный контакт, например, если считаете для себя основным XMPP. С надеждой, что остальные девайсы это сообщение самого себе подхватится.
Особенно мерзко получить длинный урл на сотку (особенно Quoted Printable) и пытаться его набрать на компе.
Не усложняйте модель добавлением лишних и ненужных компонентов вроде Jabber и mail.ru, сейчас речь идёт про аську.
История для ICQ (в будущем) или MRIM, если mail.ru это организует/организовал — я не пользуюсь, поэтому не в курсе, синхронизируется на всех клиентах, и на толстом, и через веб интерфейс, в кипе есть поиск по истории и метаконтакты.
История для ICQ (в будущем) или MRIM, если mail.ru это организует/организовал — я не пользуюсь, поэтому не в курсе, синхронизируется на всех клиентах, и на толстом, и через веб интерфейс, в кипе есть поиск по истории и метаконтакты.
насколько я понял, скайп не все сообщения пихает на подключенный клиент, а только недавние за определенное время, или определенное их число. Я точные значения этих параметров не знаю. Тут действительно можно сделать настройку и предусмотреть какие-то разумные умолчания, вроде недели и 100 сообщений, например.
Все. Вчера наблюдал, как приятель включил мобильный скайп, который не запускал около двух месяцев, и оно стянуло всю историю за это время. А сам я, когда на свою мобилу его ставил, видел, как он начал двухлетней давности историю показывать, но я его вовремя остановил.
У меня есть возможность выбора за вчера, неделю, 30 дней, все.
Более того, свежеустановленный скайп может стянуть историю переписки с любого из собеседников, пока они есть в сети. Или даже с самого себя, запущенного на другой машине, где есть полная история этой самой переписки.
Честно — не задумывался — я редко звоню по скайпу.
ага особенно удобно жене читать всю историю в ралтайме, когда вы на работе делитесь с друзьями подробностями…
Согласен с предыдущими ораторами. То, как сделано в скайпе — привычно и удобно.
А если смотреть по последней активности, то получается, что ты переписываешься с рабочего места, убегаешь куда-то на совещание или обед и с собой только телефон с запущенной аськой, и туда ты ничего не получишь, пока сам активность не проявишь?
А если смотреть по последней активности, то получается, что ты переписываешься с рабочего места, убегаешь куда-то на совещание или обед и с собой только телефон с запущенной аськой, и туда ты ничего не получишь, пока сам активность не проявишь?
Напишу здесь чтобы далеко не ходить)
Синхронизация истории как у скайпа — это плюс.
Ненавязчивое сообщение о приходе нового сообщения — явно плюс. А не то что у аси — «ОоУ. Но некоторых это и смущает.
Предлагаю по активности на ПК делалть выводы о местанахождении человека и из этого решать оповещать его или нет. Историю синхронизируем по умолчанию.
Сценарий такой — вы работали — ася Оо-кала на компе. 7 минут неактивности на компе — делаем вывод что человек покинул место — отключаем звук прихода новых сообщений на компе (но сообщения приходят и визуально показываем что есть новые сообщения (бейджи)) — в это же время включаем звук на мобильном клиенте. Когда человек проявит активность на мобильном клиенте снимаем все бейджи и помечаем сообщения прочитанными на компе (так как они прочитываются на мобильном). Но при 7 минутах не активности и на мобильной версии — возвращаем звуковое оповещение и там и там. Ну и даем понастраивать кому надо.
Вместо „7 минут неактивности“ можно сменить на „7 минут неактивности + 3 минуты не ответа на непрочитанное сообщение“.
Синхронизация истории как у скайпа — это плюс.
Ненавязчивое сообщение о приходе нового сообщения — явно плюс. А не то что у аси — «ОоУ. Но некоторых это и смущает.
Предлагаю по активности на ПК делалть выводы о местанахождении человека и из этого решать оповещать его или нет. Историю синхронизируем по умолчанию.
Сценарий такой — вы работали — ася Оо-кала на компе. 7 минут неактивности на компе — делаем вывод что человек покинул место — отключаем звук прихода новых сообщений на компе (но сообщения приходят и визуально показываем что есть новые сообщения (бейджи)) — в это же время включаем звук на мобильном клиенте. Когда человек проявит активность на мобильном клиенте снимаем все бейджи и помечаем сообщения прочитанными на компе (так как они прочитываются на мобильном). Но при 7 минутах не активности и на мобильной версии — возвращаем звуковое оповещение и там и там. Ну и даем понастраивать кому надо.
Вместо „7 минут неактивности“ можно сменить на „7 минут неактивности + 3 минуты не ответа на непрочитанное сообщение“.
Внизу тоже самое пишут)
>так как они прочитываются на мобильном
Кто сказал, что все они будут прочитаны?
Кто сказал, что все они будут прочитаны?
Мобильный клиент
Аська сменила свое поведение и теперь прочитанными сообщения считаются только тогда, когда они реально прочитаны (открыты), а не когда доставлены клиенту?
Я не разработчик аськи и даже не интересующийся. Сценариев на все случаи жизни можно написать и для новых и старых клиентов. Надо просто это сделать. Удобство привлекает людей, поэтому я перестал пользоваться асей.
Мне кажется мои слова можно переиначить как — клиентам надо посоветовать поддерживать еще один параметр — пользуется ли человек в данный момент приложением
Я про очень бесившее меня поведение в аське, когда я ею активно пользовался — логинишься, получаешь уведомление «100500 новых сообщений», по каким-то причинам перелогиниваешься и все сообщения уже как бы прочитанные.
Как приложение может узнать, пользуются ли им сейчас, если оно в подавляющем большинстве случаев используется как фоновое?
Как приложение может узнать, пользуются ли им сейчас, если оно в подавляющем большинстве случаев используется как фоновое?
Ну в момент то когда вы им пользуетесь оно открыто, а подробнее я выше написал.
Мобильный всегда с вами, логично ему передавать приоритет на «бытие онлайн» (и получение сообщений) лучше чем оставлять на десктопе.
Мобильный всегда с вами, логично ему передавать приоритет на «бытие онлайн» (и получение сообщений) лучше чем оставлять на десктопе.
Пускай даже я им пользуюсь активно, пускай прочитаю 90 сообщений из 100 (скажем, на работе по работе), но 10 (личных) останутся непрочитанными (до конца рабочего дня) — перелогин (а тем более логин на другом девайсе/клиенте) и я не смогу их прочитать, по крайней мере, как непрочитанные.
Вообще, люди даже если и работают с несколькими устройствами, то редко это происходит в самом деле параллельно. Если же и происходит, то люди, как мне кажется, будут ожидать от всех экземпляров приложения синхронных действий.
А если при подключении более одного устройства именно у отправителя будет отображаться информация об устройствах и ему выбирать, на какое отправить сообщение?
Пример: я хочу написать Васе и вижу что он онлайн пс клиентом и айфон клиентом.При этом время 18.30.Из чего я заключаю, что Вася балбес и снова забыл выключить рабочий комп и посылаю сообщение на айфон.
Пример: я хочу написать Васе и вижу что он онлайн пс клиентом и айфон клиентом.При этом время 18.30.Из чего я заключаю, что Вася балбес и снова забыл выключить рабочий комп и посылаю сообщение на айфон.
Во-первых, это противоречит концепции ленивого пользователя.
Во-вторых, требует изменений на клиентах, т. е. в любом случае, даже если в будущем поддержать, сейчас, для пользователей старых клиентов нужно какое-то разумное поведение по умолчанию.
Во-вторых, требует изменений на клиентах, т. е. в любом случае, даже если в будущем поддержать, сейчас, для пользователей старых клиентов нужно какое-то разумное поведение по умолчанию.
а зачем тебе то выбирать? просто отправь и не думай об этом, а Вася получит сообщение где захочет )
Через джаббер транспорт можно было давно исопльзовать один ICQ UIN с нескольких мест, за счет того что он был запущен на сервере, а клиенты все были на xmpp
Совершенно подтверждаю справедливость примера скайпа:
1) Одновременное подключение возможно.
2) Вся переписка дублируется на все устройства.
3) Более того, полная переписка восстанавливается на всех устройствах, даже если некоторые были выключены в течение разговора
В виду того, что мылру имеет в руках оба протокола — и MRIM, и OSCAR, я бы посоветовал внедрить это в обоих подконтрольных протоколах.
Более того, в виду присоединения магента к экосистеме Jabber, рекомендую стартовать XMPP сервер с таким же свойством мультилогина и «непрерывного разговора»
Это мылру будет полезно даже в их отношениях с уполномоченными органами. ;-)
А если нафантазировать дальше, то мылру мог бы (как и кип) шлюзовать сообщения между разными протоколами, сконсолидировав на своём клиенте почти всю клиентуру IM. А с этим выходить на .COM
1) Одновременное подключение возможно.
2) Вся переписка дублируется на все устройства.
3) Более того, полная переписка восстанавливается на всех устройствах, даже если некоторые были выключены в течение разговора
В виду того, что мылру имеет в руках оба протокола — и MRIM, и OSCAR, я бы посоветовал внедрить это в обоих подконтрольных протоколах.
Более того, в виду присоединения магента к экосистеме Jabber, рекомендую стартовать XMPP сервер с таким же свойством мультилогина и «непрерывного разговора»
Это мылру будет полезно даже в их отношениях с уполномоченными органами. ;-)
А если нафантазировать дальше, то мылру мог бы (как и кип) шлюзовать сообщения между разными протоколами, сконсолидировав на своём клиенте почти всю клиентуру IM. А с этим выходить на .COM
Отправлять на все включенные месенджеры, ничего в этом страшного нет. Ибо когда с одного месенджера вы будите пересаживать на другой, то к примеру через час опять начнете переписку а предыдущая была на другом девайсе, нужно будет вспоминать о чём речь и т.д.
Мне нравится система работы Gtalk — отправлять сообщение туда, где была зарегистрирована последняя активность пользователя. Потому что я, сидя за компьютером, не хочу получать сообщения на телефон. И наоборот, когда я на телефоне, то не хочу чтобы на компьютере они всплывали. Но при этом нужно иметь глобальную историю в облаке, как это предлагает Google — чтобы независимо от того, откуда велась переписка, не пришлось судорожно вспоминать где искать нужное сообщение.
А по поводу последней активности — сделать запуск приложения на телефоне сигналом активности, переводя фокус на него. В дальнейшем, при возвращении к компьютеру, простая смена авто-Away статуса на Available снова переключит активность на компьютер. Не идеальный вариант, но как идея.
В принципе, устроит и одновременная отправка сообщений на все устройства, с одним исключением — не охота при оживленной переписке наблюдать как все сообщения валятся к тому же и на мобильный телефон, который начинает просыпаться и судорожно нам об этом напоминать.
А по поводу последней активности — сделать запуск приложения на телефоне сигналом активности, переводя фокус на него. В дальнейшем, при возвращении к компьютеру, простая смена авто-Away статуса на Available снова переключит активность на компьютер. Не идеальный вариант, но как идея.
В принципе, устроит и одновременная отправка сообщений на все устройства, с одним исключением — не охота при оживленной переписке наблюдать как все сообщения валятся к тому же и на мобильный телефон, который начинает просыпаться и судорожно нам об этом напоминать.
А мне кажется Gtalk это как раз отрицательный пример — кроме разве что хранения хистори в облаке.
У меня и у моих друзей он обычно запущен на трех девайсах: домашний компьютер, рабочий компьютер и телефон. Переодически мы все отходим от рабочего компьютера или смотрим что-то на телефоне. Переписка при этом получается рваной — никогда не знаешь какой девайс сейчас активен, на какой ушло очередное сообщение и когда тебе ответят.
У меня и у моих друзей он обычно запущен на трех девайсах: домашний компьютер, рабочий компьютер и телефон. Переодически мы все отходим от рабочего компьютера или смотрим что-то на телефоне. Переписка при этом получается рваной — никогда не знаешь какой девайс сейчас активен, на какой ушло очередное сообщение и когда тебе ответят.
Я тоже постоянно использую Gtalk, правда не через нативный клиент. И сообщения видно везде, вне зависимости куда они пришли — просто нотификейшн не всплывает. То есть, переписываясь через Trillian, я всегда могу открыть вкладку, где у меня запущен Gmail и увидеть там открытое окно чата со всеми сообщениями. И продолжить, если это необходимо.
На самом деле хранение истории в облаке и «неразрывный» разговор — уже давно реализованы сторонними сервисами. Все что требуется от «аськи» — не вылетать.
На самом деле хранение истории в облаке и «неразрывный» разговор — уже давно реализованы сторонними сервисами. Все что требуется от «аськи» — не вылетать.
Думаю, что доставлять надо всем, однако можно вместе с сообщением прислать флаг, сигнализирующий о том, что сообщение доставлено на несколько клиентов.
Пусть клиент сам решает выводить ему уведомление или нет. (Компьютер, например, — согласно активности, и сессии пользователя, у телефона есть гироскоп) В любом вопрос о выводе или скрытии нотификаций — это вопрос решаемый на стороне клиента согласно его локальным настройкам.
Пусть клиент сам решает выводить ему уведомление или нет. (Компьютер, например, — согласно активности, и сессии пользователя, у телефона есть гироскоп) В любом вопрос о выводе или скрытии нотификаций — это вопрос решаемый на стороне клиента согласно его локальным настройкам.
1) доставлять всем, а звук проигрывать только на том, где была замечена последняя активность, при этом, необходимо учесть текущий статус, если он не «online», то звук не проигрывать.
2) с неофициальными клиентами не получится нормально сделать, поэтому нужно какую-то команду о воспроизведении звука отсылать они со временем все сами сделают
2) с неофициальными клиентами не получится нормально сделать, поэтому нужно какую-то команду о воспроизведении звука отсылать они со временем все сами сделают
Вариант скайпа предпочтителен в виду отсутствия приоритетов клиентов.
еще пожелания:
сделать jabber сервер с JIDами вида @icq.com
дать возможность делать алиасы вида nickname@icq.com, скажем, через веб-интерфейс.
еще пожелания:
сделать jabber сервер с JIDами вида @icq.com
дать возможность делать алиасы вида nickname@icq.com, скажем, через веб-интерфейс.
Приоритеты в jabber: www.jabberworld.info/%D0%9F%D1%80%D0%B8%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D1%82
Я думал, никто так и не предложит.
Это — первая мысль, которая возникла при прочтении топика…
Это — первая мысль, которая возникла при прочтении топика…
> Это — первая мысль, которая возникла при прочтении топика…
аналогично. :)
аналогично. :)
1. Частично это правильно. Но если всегда ориентироваться на старые клиенты делать что-то новое будет сложно. Это все равно, что связывать себе руки.
В крайнем случае, можно ввести новую версию протокола, а старую оставить для обратной совместимости. В старой будут приходить сообщения на все устройства или же будет доступно подключение только с одного (это вам решать), а на новой будут доступны удобные приоритеты и синхронизация истории. Популярные клиенты сделают поддержку нового протоколов, а старые будут пользоваться старым.
Это не очень удобно, но это компромисс на который ICQ уже шел.
2. В клиентах, которые поддерживают Jabber есть два типа установки приоритета, которые могут пересекаться или встречаться по отдельности от клиента к клиенту:
-Ручное задание приоритета
-Автоматическое задание приоритета в зависимости от активности или еще чего-либо.
В крайнем случае, можно ввести новую версию протокола, а старую оставить для обратной совместимости. В старой будут приходить сообщения на все устройства или же будет доступно подключение только с одного (это вам решать), а на новой будут доступны удобные приоритеты и синхронизация истории. Популярные клиенты сделают поддержку нового протоколов, а старые будут пользоваться старым.
Это не очень удобно, но это компромисс на который ICQ уже шел.
2. В клиентах, которые поддерживают Jabber есть два типа установки приоритета, которые могут пересекаться или встречаться по отдельности от клиента к клиенту:
-Ручное задание приоритета
-Автоматическое задание приоритета в зависимости от активности или еще чего-либо.
Как по мне то лучше всего сразу получать всем клиентам, потому что для меня важно history и заходить например на iPhone клиент ради того что бы посмотреть историю не охота, а так везде будет сохранена
остается только согласиться с выше высказавшимися:
1. сообщения на все устройства
2. синхронизация переписки
— все как в скайпе!
1. сообщения на все устройства
2. синхронизация переписки
— все как в скайпе!
— все как в скайпе!
за исключением нотификейшинов, пусть оно синхронизирует, но тихонько :)
Но с записью в логе типа: Загружены сообщения в history для следующих контактов:…
и список в виде UIN+никнейм контакта в моем клиенте.
Если в списке 2-3 сотни контактов, и сегодня появился кто-то новый, при продолжении разговора с ним на другом устройстве бывает минут 10 список листаешь и пытаешься вспомнить его никнейм.
и список в виде UIN+никнейм контакта в моем клиенте.
Если в списке 2-3 сотни контактов, и сегодня появился кто-то новый, при продолжении разговора с ним на другом устройстве бывает минут 10 список листаешь и пытаешься вспомнить его никнейм.
Всё как в скайпе, вот только давайте текстовое общение будет нормальным, и сообщения будут доходить здесь и сейчас, а не «как в скайпе», который при дохлом коннекте с телефона может принять сообщения завтра, послезавтра, никогда, etc.
Было бы классно, если бы сделали еще сохранение переписки на сервере с указанием IP и клиент-приложений.
P.S. Я за отправку сообщений на все подключенные соединения. Но при этом сделать так, что бы отправленные с одного устройства сообщения также отображались и на другом в режиме реального времени.
P.S. Я за отправку сообщений на все подключенные соединения. Но при этом сделать так, что бы отправленные с одного устройства сообщения также отображались и на другом в режиме реального времени.
Так в XMPP же есть приоритет ресурса? Зачем придумывать что-то новое?
Приоритет — целое число, определённое для КАЖДОГО ресурса, и передаваемое клиентом(ам) как часть информации о присутствии. Стандартом допускаются приоритеты от -128 до +127, обычно используются приоритеты от 0 до 127 (отрицательные имеют специальное значение и не все программы-клиенты их допускают).
Приоритет определяет, какому из одновременно подключенных клиентов будет доставлено сообщение, если оно послано на неполный JID (на JID без указания ресурса). Сообщение в первую очередь придет клиенту с наивысшим приоритетом. Если таковых окажется несколько, то, как сказано в описании протокола XMPP, «сервер решает», кому будет доставлено послание. У большинства серверов сообщение доставляется всем клиентам с одинаковым приоритетом.
Некоторые серверы действуют немного иначе: сервер Google (JID'ы *@gmail.com) доставляет сообщение всем одновременно подключенным клиентам, если их приоритеты ниже 32. (Другими словами: приоритеты от 0 до 31 сервер gmail.com считает одним приоритетом.)
Если приоритет отрицателен, то сообщение придёт соответствующему ресурсу только в том случае, если оно послано именно ему по полному JID (c указанием ресурса).
Приоритет — целое число, определённое для КАЖДОГО ресурса, и передаваемое клиентом(ам) как часть информации о присутствии. Стандартом допускаются приоритеты от -128 до +127, обычно используются приоритеты от 0 до 127 (отрицательные имеют специальное значение и не все программы-клиенты их допускают).
Приоритет определяет, какому из одновременно подключенных клиентов будет доставлено сообщение, если оно послано на неполный JID (на JID без указания ресурса). Сообщение в первую очередь придет клиенту с наивысшим приоритетом. Если таковых окажется несколько, то, как сказано в описании протокола XMPP, «сервер решает», кому будет доставлено послание. У большинства серверов сообщение доставляется всем клиентам с одинаковым приоритетом.
Некоторые серверы действуют немного иначе: сервер Google (JID'ы *@gmail.com) доставляет сообщение всем одновременно подключенным клиентам, если их приоритеты ниже 32. (Другими словами: приоритеты от 0 до 31 сервер gmail.com считает одним приоритетом.)
Если приоритет отрицателен, то сообщение придёт соответствующему ресурсу только в том случае, если оно послано именно ему по полному JID (c указанием ресурса).
Я тоже за доставку всем клиентам, это упростит работу с ICQ для новых мобильных ОС, использующих PUSH.
Мне сложно представить алгоритм, который позволял бы полностью синхронизировать историю на всех устройствах без создания существенной нагрузки на сервер.
Скайп не очень хороший пример, потому что с оффлайн сообщениями там беда (и, насколько могу судить, синхронизация выполняется при участии своих же клиентов или клиентов собеседника).
Скайп не очень хороший пример, потому что с оффлайн сообщениями там беда (и, насколько могу судить, синхронизация выполняется при участии своих же клиентов или клиентов собеседника).
Хотя вариант с синхронизированной историей на всех клиентах — идеал. Я практически не использую ICQ на телефоне по той причине, что если я получу какие-то сообщения, то я не увижу их в истории на основной рабочей машине, что для меня очень критично (95% переписки — работа).
В скупе сообщения синхронизятся только если «собеседник» вошел в онлайн, а пока он не войдет — историю сообщ. я не получу
Насколько я помню, два инстанса скайпа от одного юзера могут друг с друга перетягивать историю.
Если например я напишу *с работы* *кому-то* сообщение, выключу скайп, *кто-то* тоже выключит скайп, я прийду *домой*, включу скайп — история мне не прийдет ровно до того момента как этот *кто-то* не включит скайп, или я не включу одновременно скайп находящийся *на работе* и *дома*. Т.е. пока один из собеседников учавствовавших в предыдущей беседе не зайдет в сеть.
Согласен. Просто зачастую *на работе* скайп остаётся включённым в «away» (по крайней мере, большинство моих собеседников делают именно так), потому я даже не рассматривал случай поочерёдной доступности.
А я вот заметил,
например вечер, беседа из дому:
человек вышел из скайпа, я в догонку написал, что-то типа «пока»,
следующий день, беседа на работе с другого инстанса скайпа (сообщение «пока» осталось в домашней скайпе).
вечер этого же дня, при входе издому собеседнику идет вообще не в тему старое сообщение «пока».
И вот так у меня часто, как-то не удобно.
например вечер, беседа из дому:
человек вышел из скайпа, я в догонку написал, что-то типа «пока»,
следующий день, беседа на работе с другого инстанса скайпа (сообщение «пока» осталось в домашней скайпе).
вечер этого же дня, при входе издому собеседнику идет вообще не в тему старое сообщение «пока».
И вот так у меня часто, как-то не удобно.
Так там же дата будет и время указаны, оно просто вклинится между старых сообщений. Не так страшно это.
Жалко очень, что кроме скайпа никто это не умеет больше.
Жалко очень, что кроме скайпа никто это не умеет больше.
Ну по-моему оффлайн сообщения в той же аське удобнее, если я отправляю в догонку, то это сообщение прийдет при первом входе собеседника в сеть. Вот только синхронизации не хватает.
Так в этом-то и принципиальная разница, в скайпе просто негде хранить оффлайновые сообщения.
Ну где-то же хранится информация о пользователях, вот туда бы и историю:) Хотя, возможно, их распределенная схема не позволяет так, в любом случае эта схема, по-моему, плохо подходит для аськи
Надо сказать, я уже достаточно давно продумываю схему полностью распределённого мессенджера, в котором информация о пользователях не будет храниться вообще нигде, кроме их собственных машин. Надо сказать, проблемы в этом большой нет, только разве что в том, что такой сетью «владеть» сложно — нет центра, из которого можно кого-то централизованно забанить, например.
Винт сгорел и всё? Спасение утопающих дело рук самих утопающих?
А как Вы решаете проблему, например, с SSH- и GnuPG-ключами? Вот так и здесь.
Ключи маленькие, способов бэкапа их миллион, включая простую распечатку на простой бумаге. Кроме того, они не меняются по сто раз за день.
Так а в чём здесь проблема бекапить маленькие ключи, которые не будут меняться по сто раз за день?
>в котором информация о пользователях не будет храниться вообще нигде, кроме их собственных машин.
История переписки может меняться и чаще, чем сто раз за день. Или история переписки пользователя это не информация о пользователе?
История переписки может меняться и чаще, чем сто раз за день. Или история переписки пользователя это не информация о пользователе?
Собственно, проблема на данный момент у меня только одна — нет времени взяться за реализацию даже прототипа.
Почему-то не вижу смысла держать всё «при себе», по-моему у джаббера достаточная децентрализованность.
Нет, жаббер не децентрализован в той мере, в которой хотелось бы. Умер сервер — что дальше? Он децентрализован лишь в той мере, что серверов много, но клиенты сами по себе беспомощны.
Вот оно че, теперь понял идею.
Но по-моему единственный способ реализации безопасности такого месседжера — соединение через внешний айпи каждого пользователя, и передачу сообщений уже просто по сокетам.
Но по-моему единственный способ реализации безопасности такого месседжера — соединение через внешний айпи каждого пользователя, и передачу сообщений уже просто по сокетам.
А как Вы думаете, скайп это делает? Просто в нём есть ахиллесова пята в виде сервера авторизации, без которого вполне можно обойтись. Ну и проприетарно-закрытый он.
Ну вот через этот сервер он и делает, без него по-моему без айпи не подключишься клиентом к клиенту
Нет, он подключается напрямую. Принцип похожий на то, что в торрентах.
Не знаю как, но я затруднений при коннекте из-за провайдерского НАТа не испытываю. То есть сервер не только обеспечивает авторизацию, но и (как и в торрентах) гоняет айпишники клиентов, готовых принимать входящие подключения.
А причём здесь NAT? Я вроде как ничего не говорил про него, да и про «протыкание» NAT вроде как все знают… И да, с сервера происходит бутстрап сети, но это не значит, что коннекты идут через него. Так или иначе, в жаббере это всё сделано совсем по-другому.
>Просто в нём есть ахиллесова пята в виде сервера авторизации, без которого вполне можно обойтись.
Я про это. Пускай без сервера авторизации мы обойдёмся, но сервер, который будет рассылать список доступных для подключения узлов всё равно нужен, а значит ахиллесова пята останется.
Я про это. Пускай без сервера авторизации мы обойдёмся, но сервер, который будет рассылать список доступных для подключения узлов всё равно нужен, а значит ахиллесова пята останется.
Вовсе нет. Во-первых, таких серверов может быть много, причём по-хорошему таким сервером может являться любой узел сети, а во-вторых, у нас может быть локальный кеш на n узлов сети.
Кроме того, можно использовать инфраструктуру DNS для повышения вероятности того, что узлы будут on-line — например, узлы с очень большим аптаймом могут вноситься запиcями типа A и AAAA в какой-нибудь dht-bootstrap.mega-super-messenger.org.
Кроме того, можно использовать инфраструктуру DNS для повышения вероятности того, что узлы будут on-line — например, узлы с очень большим аптаймом могут вноситься запиcями типа A и AAAA в какой-нибудь dht-bootstrap.mega-super-messenger.org.
Точнее, не «вовсе нет», но вероятность «убивания» сети гораздо меньше.
Не такая уж и нагрузка большая для мылору хранить историю сообщений на своих серверах
Не только хранить, но и помнить, какие клиенты пользователя получали конкретные сообщения.
клиент сам может помнить айдишку последнего сообщения которое у него есть
тут еще могут возникнуть проблемы наподобие:
пользователь установил аську на телефон, немного пообщался, вышел
забыл про нее на день/месяц/год
снова подключился, сколько ему присылать сообщений? за весь год?
могут возникнуть либо магические константы, либо дополнительные настройки, либо проблемы безопасности
пользователь установил аську на телефон, немного пообщался, вышел
забыл про нее на день/месяц/год
снова подключился, сколько ему присылать сообщений? за весь год?
могут возникнуть либо магические константы, либо дополнительные настройки, либо проблемы безопасности
Не знаю, может у меня одного параноя, но если я вижу надпись «Ваш ICQ UIN запущен на другом компьютере» сразу хватаюсь за сердце с мыслями «угоняют»…
Если у вас делается аналог ресурсов в Jabber (когда ресурс — это некое символьное расширение JID, уникально идентифицирующее конкретный инстанс запущенный на каком-то из устройств типа:
userbane@example.org/home
userbane@example.org/work
userbane@example.org/notebook
userbane@example.org/mobile
(причём обмен сообщениями возможен даже между разными ресурсами одного JID)
То алгоритм доставки, по-моему, должен быть такой:
1. Если сообщение отправляется на конкретный ресурс, то доставлять только на него.
2. Если сообщение отправляется на сам JID без указания ресурса, то доставлять его всем.
Если у вас будет реализовано не просто тегирование инстансов одного контакта (типа ресурсов в XMPP), но у каждого будет выставлен некий приоритет (как в XMPP), то можно доставлять согласно приоритету. Т.е. если сообщение отправлено без указания конкретного ресурса, то доставлять его ресурсу с максимальным приоритетом (или несколькои, если максимальный приоритет установлен сразу у нескольких). А если с указанием конкретного ресурса — то доставлять только ему, независимо от приоритетов.
userbane@example.org/home
userbane@example.org/work
userbane@example.org/notebook
userbane@example.org/mobile
(причём обмен сообщениями возможен даже между разными ресурсами одного JID)
То алгоритм доставки, по-моему, должен быть такой:
1. Если сообщение отправляется на конкретный ресурс, то доставлять только на него.
2. Если сообщение отправляется на сам JID без указания ресурса, то доставлять его всем.
Если у вас будет реализовано не просто тегирование инстансов одного контакта (типа ресурсов в XMPP), но у каждого будет выставлен некий приоритет (как в XMPP), то можно доставлять согласно приоритету. Т.е. если сообщение отправлено без указания конкретного ресурса, то доставлять его ресурсу с максимальным приоритетом (или несколькои, если максимальный приоритет установлен сразу у нескольких). А если с указанием конкретного ресурса — то доставлять только ему, независимо от приоритетов.
Какой клиент позволяет указывать адресата как home/work/laptop/mobile?
да тот же квип: wiki.qip.ru/Ресурс
Да многие jabber-клиенты такое поддерживают: Psi, Psi+, Tkabber и др.
Плевать на невозможнссть одновременно запускать клиент с нескольких компьютеров, больше волнует история. Хочу синхронизацию без сторонних утилит и шаманств с бубном.
может поиграться со статусами? там где online, на тот и отправлять. а тот где away, ставить в ожидание
Возможно я параноик, но мне кажется, что теперь не определишь — угнал твой номер злобный троян, забыл ли ты убрать пароль от учетки, когда был не за своим компом, или еще где «засветил» свои credentials. Фэйл вобщем.
Но если так и будет — то как выше говорили, нужно сделать алгоритм как у скайпа + логирование с какого клиента и откуда было послано сообщение. Еще было бы круто реализовать хранение истории на сервере в закрытом виде, а-ля GTalk.
Но если так и будет — то как выше говорили, нужно сделать алгоритм как у скайпа + логирование с какого клиента и откуда было послано сообщение. Еще было бы круто реализовать хранение истории на сервере в закрытом виде, а-ля GTalk.
А вообще хватит изобретать велосипеды.
Переводите уже ICQ на протокол XMPP.
Переводите уже ICQ на протокол XMPP.
Да ладно, OSCAR тоже не такой плохой протокол, вопрос же не в этом, а в инфраструктуре и том, что обычно называют словом «интероперабельность»
Я серьёзно. Лично мне плевать, какой протокол используется для доставки сообщений на сервер от ICQ-клиента. Мне важно, чтобы этот самый сервер мог отдать их потом в другую сеть, ну и наоборот, естественно. Какая разница, что там на транспортном уровне? Протокол расширяемый? Да! Значит, проблема не в нём, пусть остаётся. Все эти фишки, о которых идёт речь как в этой статье, так и в комментариях, можно реализовать в рамках того протокола, что есть сейчас, просто старые клиенты не будут о них подозревать.
1. Посылать сообщения на все клиенты. Если клиент оффлайн, то при онлайне получает все новые, пока он был оффлайн. Этим реализуется и глобальная история.
2. При прочтении сообщения на любом клиенте изменять его статус на прочтенные во всех клиентах.
Так мы получим и отсутствие сотен уведомлений на десктопе, если целый день переписывались с телефона и возможность продолжать разговор, когда добрались-таки до десктопа.
2. При прочтении сообщения на любом клиенте изменять его статус на прочтенные во всех клиентах.
Так мы получим и отсутствие сотен уведомлений на десктопе, если целый день переписывались с телефона и возможность продолжать разговор, когда добрались-таки до десктопа.
Самая толковая схема.
Спасибо :)
Писал выше, но добавлю и тут: загрузку всех новых можно (и даже нужно) реализовать лениво, чтобы не скачивать на новый мобильник всю переписку со всеми контактами за 10 лет, а скачивать только то, что реально нужно. То есть при логине посылать клиенту агрегированную информацию типа «всего сообщений столько-то, непрочитанных (глобально!) сообщений от таких-то контактов столько-то (ну и их „тизеры“ для отображения)». А грузить когда пользователь захочет что-то увидеть конкретно и только то. Например, сначала непрочитанные сообщения конкретного контакта, потом историю за сегодня, потом вчера, потом неделю, месяц, год,…
Упреждающую загрузку тоже никто не отменял, но вот она должна быть настраиваемой пользователем и по дефолту, как минимум для мобильных устройств, минимальной или вообще отключена.
Писал выше, но добавлю и тут: загрузку всех новых можно (и даже нужно) реализовать лениво, чтобы не скачивать на новый мобильник всю переписку со всеми контактами за 10 лет, а скачивать только то, что реально нужно. То есть при логине посылать клиенту агрегированную информацию типа «всего сообщений столько-то, непрочитанных (глобально!) сообщений от таких-то контактов столько-то (ну и их „тизеры“ для отображения)». А грузить когда пользователь захочет что-то увидеть конкретно и только то. Например, сначала непрочитанные сообщения конкретного контакта, потом историю за сегодня, потом вчера, потом неделю, месяц, год,…
Упреждающую загрузку тоже никто не отменял, но вот она должна быть настраиваемой пользователем и по дефолту, как минимум для мобильных устройств, минимальной или вообще отключена.
Правильным было бы отправлять все сообщения на клиент, который проявил последнюю активность (отправил сообщение, например). Если в сети появился новый клиент — пересылать ему непрочитанные сообщения (неотвеченные).
Синхронизацию истории на всех клиентах стоит сделать опциональной (при том фоновой) фичей — не все будут готовы доверить вашим серверам свою хистори.
Синхронизацию истории на всех клиентах стоит сделать опциональной (при том фоновой) фичей — не все будут готовы доверить вашим серверам свою хистори.
Я «за» то что бы сообщения улетали на все открытые соединения на момент отправки сообщения. А лучше как в скайпе сделать. Мне так крайне удобно. ИМХО конечно
Мне нравится, как в этом плане работает клиент «Я.Онлайн» для компьютера и клиент «Я.Почта» для айфона (в нём есть встроенный XMPP-чат). В последнем можно установить приоритетный клиент: компьютер или телефон. Когда забываю закрыть клиент на десктопе, просто переключаю эту галку и всё.
Если прибавить к этому icq-транспорт, который решает проблему множественного входа, а так же общую онлайн историю, то, собственно, реализация довольно неплохая.
Если прибавить к этому icq-транспорт, который решает проблему множественного входа, а так же общую онлайн историю, то, собственно, реализация довольно неплохая.
Да, раз уж вы решили послушать наши фичереквесты — сделайте icq-контакты доступными из жаббера по уидам вида number@icq.com
Гиков вы уже давно потеряли, зато мы перестанем призывать всех хомяков перейти на нативный xmpp. А нас избавите от необходимости использовать транспорт к вам.
И mra давно бы уже так организовали.
Гиков вы уже давно потеряли, зато мы перестанем призывать всех хомяков перейти на нативный xmpp. А нас избавите от необходимости использовать транспорт к вам.
И mra давно бы уже так организовали.
Если Mail.ru пойдут на это, я начну их уважать :)
Вот только проблема в спаме. То есть при этом из неподконтрольной Mail.ru части сети может литься спам к ним. Это можно решить авторизациями, которые уже есть в обоих протоколах. Без авторизации, к примеру, может быть невозможно посылать сообщения или послать только одно.
Ну во-первых он прекрасно льётся из из под контрольной части сети =)
Во-вторых проблема действительно решаема — можно сделать некоторые ограничения. Можно сделать необходимость привязывать uin к жаббер аккаунту, проверять насколько этот uin живой (нормальный контакт лист, нормальное общение, отсутствие жалоб на спам) и разрешать добавлять контакты только в такие аккаунты (естественно, чтобы можно было добавлять любые uin'ы, а не только те, которые есть в твоём).
Во-вторых проблема действительно решаема — можно сделать некоторые ограничения. Можно сделать необходимость привязывать uin к жаббер аккаунту, проверять насколько этот uin живой (нормальный контакт лист, нормальное общение, отсутствие жалоб на спам) и разрешать добавлять контакты только в такие аккаунты (естественно, чтобы можно было добавлять любые uin'ы, а не только те, которые есть в твоём).
Как вариант, кстати — официальный транспорт. Не глючные письки и спектрумы, а нормальный транспорт, который работал бы у них и был бы написал под их платформу.
Саш, очень прошу сделать так, чтоб не повторить секурной ошибки Skype — когда один гондон украл у меня пароль от скайпа, он смог какое-то время читать мою переписку с другими людьми (т.к. на его компьютер подгружалась вся история переговоров, и при этом я не мог видеть, что кто-то ещё читает переписку в онлайне).
Также очень небезопасно в скайпе сделана история — когда кто-то может выйти онлайн (в инвизе), и подгрузить историю сообщений в мое отсутствие — т.к. история хранится на компах моих собеседников.
Также очень небезопасно в скайпе сделана история — когда кто-то может выйти онлайн (в инвизе), и подгрузить историю сообщений в мое отсутствие — т.к. история хранится на компах моих собеседников.
Единственное что приходит в голову — оповещать о том что под текущей учеткой зашли еще с одного девайса (и указывать IP адрес и клиент).
Ну и само собой сделать фичу с синхронизацией переписки отключаемой.
Ну и само собой сделать фичу с синхронизацией переписки отключаемой.
В Jabber часто отображается собственный контакт с показом ресурсов с которых сидишь в сети. Если использовать эту схему с более простым представлением для рядового пользователя, чтобы он понимал, что он «не один» — было бы круто.
Т.е. сделать отображение в окне чата (где-нибудь сверху информер, желательно неотключаемый) сообщение:
«Ваш ICQ-номер используется на 213.24.76.23, включена синхронизация переписки»
Но при этом надо ещё и продумать, чтоб хацкер не мог незаметно включить отключенную синхронизацию, и подгрузить историю старых сообщений (которые могли храниться в истории переписки людьми из моего контакт-листа, которые логирование/синхронизацию могли не отключать).
«Ваш ICQ-номер используется на 213.24.76.23, включена синхронизация переписки»
Но при этом надо ещё и продумать, чтоб хацкер не мог незаметно включить отключенную синхронизацию, и подгрузить историю старых сообщений (которые могли храниться в истории переписки людьми из моего контакт-листа, которые логирование/синхронизацию могли не отключать).
В последние месяцы замечал на клиенте Pidgin. Если вел переписку с работы, а потом люди продолжади писать мне в оффлайн. то сообщения мог полчить только с рабочего клиента. и наоборот. Очень сильно раздражало.
Есть более «революционное» предложение:
СДЕЛАЙТЕ БЛИН НАКОНЕЦ ВОЗМОЖНОСТЬ УСТАНОВИТЬ ПАРОЛЬ ДЛИНОЙ БОЛЕЕ ВОСЬМИ СИМВОЛОВ НА ВАШЕМ СЕРВЕРЕ ICQ
СДЕЛАЙТЕ БЛИН НАКОНЕЦ ВОЗМОЖНОСТЬ УСТАНОВИТЬ ПАРОЛЬ ДЛИНОЙ БОЛЕЕ ВОСЬМИ СИМВОЛОВ НА ВАШЕМ СЕРВЕРЕ ICQ
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Разбор «кучи нотификаций» решается глобальным флагом прочтения — на одном клиенте пользователь открыл (не получил, а именно открыл) сообщение и посылает уведомление об этом серверу, а тот сообщает остальным клиентам, что сообщение уже где-то прочтено в другом месте.
Постоянное сигнализирование решается пользователем: пищит телефон в кармане и десктоп, отключи сигнализацию в телефоне, а когда уйдешь от десктопа — включишь (можно ещё допнастройки, типа в если онлайн только один клиент, то сигнализация включается).
Постоянное сигнализирование решается пользователем: пищит телефон в кармане и десктоп, отключи сигнализацию в телефоне, а когда уйдешь от десктопа — включишь (можно ещё допнастройки, типа в если онлайн только один клиент, то сигнализация включается).
Похоже на «Все ушли в джаббер? Давайте замаскируем аську под джаббер и все вернутся!». Ну уж нет
Все ушли на джаббер это миф, по крайне мере я могу говорить это точно про россию и про свой круг друзей\знакомых 20-25 лет. ICQ пользуются все, поэтому развитие ICQ плюс для тех кто пользуется а не попытка перетащить прожженных гиков с джабера.
Для меня — все ушли на джаббер (и все ваши знакомые тоже). Как? Вконтакт… все там и по джабберу доступны. Скайп + вконтактоджаббер и я уже давно не пользуюсь асей (очень изредка для 1-2 контактов по работе)
s2s что на вконтакте, что на facebook закрыт, так что не очень-то они доступны.
клиенты с мулти подключениями умерли??
Мультипротокольные клиенты обычно умеют и icq с агентом. И совершенно не важно, что между клиентом и сервером вконтакта бегает, XMPP, MMP или Oscar, если s2s закрыт.
ну
мне как потребителю давно уже поровну (почти, из-за скайпа) что там за протоколы. на телефоне у меня мультипротокольный клиент, на десктопе тоже. Я вообще не жалуюсь — все окей.
Хотя жалуюсь. У меня нестабильный инет. И ася (единственная) кто вылетая долго восстанавливается, а когда с инетом совсем плохо — она выдает ошибку «слишком частые подключения, идите в жопу на 5 минут, а если еще будешь мне тут долбиться, вообще не подключу» — а оно мне надо?
Хотя жалуюсь. У меня нестабильный инет. И ася (единственная) кто вылетая долго восстанавливается, а когда с инетом совсем плохо — она выдает ошибку «слишком частые подключения, идите в жопу на 5 минут, а если еще будешь мне тут долбиться, вообще не подключу» — а оно мне надо?
>Для меня — все ушли на джаббер (и все ваши знакомые тоже).
>мне как потребителю давно уже поровну (почти, из-за скайпа) что там за протоколы.
Я вижу тут противоречие. Причем со вторым утверждением я согласен, а вот с первым — нет.
>И ася (единственная) кто вылетая долго восстанавливается
А какой клиент?
>мне как потребителю давно уже поровну (почти, из-за скайпа) что там за протоколы.
Я вижу тут противоречие. Причем со вторым утверждением я согласен, а вот с первым — нет.
>И ася (единственная) кто вылетая долго восстанавливается
А какой клиент?
Там нет противоречия. Ася очень сбоит по описанной проблеме и я просто не могу ей физически пользоваться и со всеми кто имеет асю я общаюсь через вконтакт (видать пересечение аудитории).
Клиент Адиум на Маке.
Ваш официальный клиент ставить не буду — адиум был вообще прекрасен пока скайп не обновился и не сломал интеграцию — чтобы не было зоопарка програм с одинаковой функцией, но разными интерфейсами.
Клиент Адиум на Маке.
Ваш официальный клиент ставить не буду — адиум был вообще прекрасен пока скайп не обновился и не сломал интеграцию — чтобы не было зоопарка програм с одинаковой функцией, но разными интерфейсами.
Из моих друзей никто не используется их как IM скорее как замена email.
У вКонтакта сейчас джаббер практически мёртвый — теряет сообщения только так.
На фри-ланс.ру большинство заказчиков оставляют аську для контактов, причём даже не поясняя, что это за цифры…
Вы говорите «ICQ пользуются все»? Неправда ваша, подавляющего большинства моих друзей того же возраста там уже нету. Те, кто использовали аську с мобилы теперь вчерз вконтакте пишут, а те кто чуть посерьезнее — ушли в скайп. Просто лично я не могу понять чем аська лучше, может вы просвятите. Разве что тем, что к ней все привыкли и ностальгия держит…
Если смотреть по мои ботам то за три года джаббер почти совсем не вырос, а вот icq на процентов 500%
>Похоже на «Все ушли в джаббер?
По моим наблюдениям, большинство переходит на мессенджер ВКонтакте.
По моим наблюдениям, большинство переходит на мессенджер ВКонтакте.
ИМХО всё просто, может повторюсь но — синхронизировать все устройства + поддержка оффлайн как это было. Скайп не удобен тем что сообщение пользователю не дойдёт если ты сам оффлайн.
Главное сделайте возможность видеть сколько еще альтернативных клиентов включено.
Скайп напрягает тем, что допустим если увели доступ, то легко могут «прослушивать» и никак это не заметишь. Уведенную аську можно было заметить по невозможности коннекта:-\
Скайп напрягает тем, что допустим если увели доступ, то легко могут «прослушивать» и никак это не заметишь. Уведенную аську можно было заметить по невозможности коннекта:-\
Поначалу не понял почему на картинке два айфона.
Если общение началось на одном устройстве по инициативе его пользователя то и продолжать на этом же устройстве пока пользователь явно не проявит желание общаться с другого (отправив с него сообщение в текущую беседу). Если инициатор общения не сам пользователь устройства, а его контакт то отправлять приоритетно на то утройство, на котором активно окно клиента (или на несколько таких устройств), если ни на одном из устройств окна не активны, то оправлять на то устройство, которое последним проявляло активность+по желанию пользователя (включается в настройках) отправляется push уведомление на мобильное устройство.
Дополнительно на компьютере можно использовать статус «отошел», при активации которого автоматически включаются push уведомления на мобильные устройства.
Дополнительно на компьютере можно использовать статус «отошел», при активации которого автоматически включаются push уведомления на мобильные устройства.
Сообщение приходят на все устройства. Но как только оно читается на одном из устрйоств, на всех остальных он помечается прочитанным и нотификация скидывается.
Так сделайте для каждого настройку в профиле на icq.com, что уж? =)
Вам надо было голосовалку сделать. Я за синхронизацию истории полную (и вх и исх) как в скайпе.
Вы бы топик-голосование сделали со всеми возможными вариантами.
1. [v] отправлять всем
2. [ ] отправлять последнему по активности
3. [ ] отправлять последнему по времени подключения
1. [v] отправлять всем
2. [ ] отправлять последнему по активности
3. [ ] отправлять последнему по времени подключения
А вообще — что вам мешает сделать это опционально и предоставить пользователю самому выбрать вариант наиболее подходящий ему?
Опция должна быть не в мессенджере, а на один UIN. Можно по идее сделать какой-то «менеджер клиентов», где были бы видны все активные залогинившиеся устройства под этим UINом, и можно было бы из 1 клиента управлять пересылкой сообщений на другие клиенты, а заодно и мониторить какие устройства сейчас подключены. Более того, в зависимости от ClientID можно было бы определять тип устройств и на основе этих типов предоставить юзеру самому выбрать политику пересылки сообщений.
Опция должна быть не в мессенджере, а на один UIN. Можно по идее сделать какой-то «менеджер клиентов», где были бы видны все активные залогинившиеся устройства под этим UINом, и можно было бы из 1 клиента управлять пересылкой сообщений на другие клиенты, а заодно и мониторить какие устройства сейчас подключены. Более того, в зависимости от ClientID можно было бы определять тип устройств и на основе этих типов предоставить юзеру самому выбрать политику пересылки сообщений.
> были бы видны все активные залогинившиеся устройства под этим UINом, и можно было бы из 1 клиента управлять пересылкой сообщений на другие клиенты
Тогда, теоретически, злоумышленник, завладевший вашим номером/паролем легко и незаметно для вас может перевести поток сообщений на себя (или нужно вводить определение какого-то мастер-клиента).
Тогда, теоретически, злоумышленник, завладевший вашим номером/паролем легко и незаметно для вас может перевести поток сообщений на себя (или нужно вводить определение какого-то мастер-клиента).
Но зато ты увидишь активность «Клиент A отключил поток данных на ваш клиент. Если это были не Вы — то отправьте ALARM, чтобы остановить действия злоумышленника.» — посылается ALARM, после чего на клиенте А зарашивается пароль, который пока не введёшь — не сможешь ничего сделать.
Ситуацию, где злоумышленник знает твой пароль — рассматривать не имеет смысла, но даже в этом случае получается какая-то секурность: любые действия злоумышленника не останутся незамеченными.
Ситуацию, где злоумышленник знает твой пароль — рассматривать не имеет смысла, но даже в этом случае получается какая-то секурность: любые действия злоумышленника не останутся незамеченными.
Skype давно и правильно всё реализовал — сделайте, пожалуйста, так же. :)
У меня проблема такая: дома закрываю ноут с включенной аськой (система засыпает, аська отключается) и ухожу на работу. На работе включаю аську и общаюсь по разным вопросам с кучей людей. В какой-то момент могу отойти от компа, а в этот момент, например, кто-то из домашних открывает мой ноут дома (система просыпается, аська дома перетягивает коннект на себя, и все сообщения уходят туда), и поскольку меня рядом с рабочим компьютером в данный момент нет, быстро переподключиться назад я не могу, и узнаЮ о том, что мне кто-то писал, только вернувшись домой. :(
В Skype такая проблема отсутствует начисто, но есть и недостаток: я не знаю, читает кто-то мою переписку или нет. Т.е. имея логин/пароль какого-либо пользователя можно совершенно незаметно наблюдать за его разговорами.
Было бы шикарно, чтобы к возможностям скайпа в аське добавили уведомление о том, сколько ещё коннектов обслуживается в рамках одного UIN и их IP-адреса, например.
У меня проблема такая: дома закрываю ноут с включенной аськой (система засыпает, аська отключается) и ухожу на работу. На работе включаю аську и общаюсь по разным вопросам с кучей людей. В какой-то момент могу отойти от компа, а в этот момент, например, кто-то из домашних открывает мой ноут дома (система просыпается, аська дома перетягивает коннект на себя, и все сообщения уходят туда), и поскольку меня рядом с рабочим компьютером в данный момент нет, быстро переподключиться назад я не могу, и узнаЮ о том, что мне кто-то писал, только вернувшись домой. :(
В Skype такая проблема отсутствует начисто, но есть и недостаток: я не знаю, читает кто-то мою переписку или нет. Т.е. имея логин/пароль какого-либо пользователя можно совершенно незаметно наблюдать за его разговорами.
Было бы шикарно, чтобы к возможностям скайпа в аське добавили уведомление о том, сколько ещё коннектов обслуживается в рамках одного UIN и их IP-адреса, например.
НЛО прилетело и опубликовало эту надпись здесь
Мне по душе следующий подход к отправлению сообщений на разные клиенты:
1) При подключении нового клиента в уже существующих выводится и/или просто принимается к сведению сообщение, что кто-то подключился, используя тот же аккаунт.
2) Каждый клиент содержит «галочку»: «не показывать уведомления, если данный аккаунт использует еще какой-то клиент».
ИМХО, и довольно гибко, и уведомляет пользователя о том что кто-то (возможно, злоумышленник) зашел под его аккаунтом.
1) При подключении нового клиента в уже существующих выводится и/или просто принимается к сведению сообщение, что кто-то подключился, используя тот же аккаунт.
2) Каждый клиент содержит «галочку»: «не показывать уведомления, если данный аккаунт использует еще какой-то клиент».
ИМХО, и довольно гибко, и уведомляет пользователя о том что кто-то (возможно, злоумышленник) зашел под его аккаунтом.
Ребята, позволю себе немного не в тему. Когда появится поддержка обоих клиентов ICQ+MailAgent в одном клиенте под Макось? Плюс Агент совсем хреново работает из-за прокси в той же макоси.
Основная проблема в том, что хочеться иметь сообщения на всех устройствах, но нет желания видеть нотификации, когда ты уже что-то прочел или одновременно на нескольких устройствах. Для этого нужны две вещи, во-первых клиент при прочтении сообщения, должен оповещать об этом сервер, чтобы когда я пришел домой у меня не появилось миллиард уже прочитанных мной на работе сообщений. Во-вторых клиенты должны иметь галочку «не показывать нотификации, если в сети есть другой клиент с таким же или более высоким статусом активности», а сервер должен отправлять сообщения в двух режимах (синхронизация истории и активное сообщение). Например у меня есть клиент на телефоне и на компе, когда я отхожу от компа, клиент регистрирует потерю активности и переводит мой статус в «отошел» (при этом на телефоне всегда статус «активен»), тогда следующее сообщение должно вызвать на телефоне нотификацию, а на компьютере просто записаться в лог.
Я тут хотел тоже начать писать про скайп и про прочие его плюшки, но вот тут подумал и остановился. Лучше сделать небольшой Device manager или Device center, в котором будут отображаться текущие подключения. И пользователь будет сам выбирать что ему и куда отправлять, на лету.
Например можно назвать пункт как «Я сейчас тут» или на подобии этого. А уже на конкретном устройстве подгружать историю по необходимости. Но при всём этом будет расти нагрузка на сервер. Поэтому можно организовать связь между клиентами на прямую, и отдать часть задач им.
С забытыми устройствами в карманах и сумках вопрос решается примерно как и у скайпа. Все новые сообщения которые не прочитаны на каком-либо устройстве приходят на тот клиент, который объявляется основным, и на остальных клиентах становятся прочитанными. Так что не забытый телефон, ни включенный компьютер на работе не станет раздражителем для остальных.
А при смене основного устройства будет рассылка на все клиенты о новом main устройстве. Так что, если ваша кошка к примеру) магией или ещё чем-то сменит устройство по умолчанию то вы об этом узнаете.
Ещё можно сделать небольшие напоминания о том что у нас, к примеру, назначено мобильное устройство как основное, если мы недавно сели за компьютер и забыли сменить устройство. При этом сообщения не будут присылаться пока не будет выяснено куда их точно отправлять.
Например можно назвать пункт как «Я сейчас тут» или на подобии этого. А уже на конкретном устройстве подгружать историю по необходимости. Но при всём этом будет расти нагрузка на сервер. Поэтому можно организовать связь между клиентами на прямую, и отдать часть задач им.
С забытыми устройствами в карманах и сумках вопрос решается примерно как и у скайпа. Все новые сообщения которые не прочитаны на каком-либо устройстве приходят на тот клиент, который объявляется основным, и на остальных клиентах становятся прочитанными. Так что не забытый телефон, ни включенный компьютер на работе не станет раздражителем для остальных.
А при смене основного устройства будет рассылка на все клиенты о новом main устройстве. Так что, если ваша кошка к примеру) магией или ещё чем-то сменит устройство по умолчанию то вы об этом узнаете.
Ещё можно сделать небольшие напоминания о том что у нас, к примеру, назначено мобильное устройство как основное, если мы недавно сели за компьютер и забыли сменить устройство. При этом сообщения не будут присылаться пока не будет выяснено куда их точно отправлять.
Сегодня чисто случайно заметил, что сидя в аське с телефона и включив на компе не был выкинут с телефона. Подумал что такой жирный глюк
ИМХО нормальным решением было бы сделать спец.кнопку а-ля «я тут», взял мобилу, ткнул в кнопку, сразу мессаги туда пошли, а на комп перестали идти. Вернулся, ткнул в компе кнопку, и снова туда летят.
И, конечно же, при неактивной галке, при отправки месседжа, она ставится автоматом!
И, конечно же, при неактивной галке, при отправки месседжа, она ставится автоматом!
Считаю идеальным вариантом выбор из трех опций — как сейчас, т.е. один активный клиент (по умолчанию), второй — сообщения приходят на все клиенты, третий — сообщения получает более активный клиент (с которого производились какие либо действия в последний раз). Пусть пользователь выбирает то что ему удобнее, да и не придется заморачиваться с синхронизацией.
присоединяюсь к вышеписавшим ораторам, подытожу своё мнение:
1) при запуске с другого клиента, выскакивает окошко, где предлагают на выбор:
— загрузить историю прямо сейчас
— не загружать, но напомнить о загрузке через 10-15-20-… минут (это как в винде: если стали обновления, можно прям сразу перегрузить, или «отложить» — через какое-то время выскочит опять напоминание, если выбрал «отложить»)
2) вся асечная история хранится на сервере. Почему бы пользователям не дать к ней доступ?
вот у меня помёр винт, наглухо. Носил в сервис — инфу не смогли восстанвоить, винт выбросили, хорошо хоть на гарантии был, заменили.
но(!), асечная история накрылась медным тазиком (как и всё другое). Получается, пользователи квипа, у которых история синхронизируется на сервере, есть возможность в любой момент через браузер зайти и посмотреть что да как. А. пользователи официальных клиентов, получается, в самом невыгодном положении.
может добавите возможность через веб-интерфейс посмотреть свою старую историю?
у меня, к примеру, номера тыща и один миллион лет, некоторые старые разговоры хотел пересмотреть
судя по тому. как пользователи квипа активно синхронизируют историю — фича вотстребованная.
1) при запуске с другого клиента, выскакивает окошко, где предлагают на выбор:
— загрузить историю прямо сейчас
— не загружать, но напомнить о загрузке через 10-15-20-… минут (это как в винде: если стали обновления, можно прям сразу перегрузить, или «отложить» — через какое-то время выскочит опять напоминание, если выбрал «отложить»)
2) вся асечная история хранится на сервере. Почему бы пользователям не дать к ней доступ?
вот у меня помёр винт, наглухо. Носил в сервис — инфу не смогли восстанвоить, винт выбросили, хорошо хоть на гарантии был, заменили.
но(!), асечная история накрылась медным тазиком (как и всё другое). Получается, пользователи квипа, у которых история синхронизируется на сервере, есть возможность в любой момент через браузер зайти и посмотреть что да как. А. пользователи официальных клиентов, получается, в самом невыгодном положении.
может добавите возможность через веб-интерфейс посмотреть свою старую историю?
у меня, к примеру, номера тыща и один миллион лет, некоторые старые разговоры хотел пересмотреть
судя по тому. как пользователи квипа активно синхронизируют историю — фича вотстребованная.
однозначно лучше сделать так же как в skype!
написал топикстартеру свой UIN, он подключил. работает теперь с двух мест сразу. когда подключаешься со второго клиента ICQ System присылает сообщение такого плана: Вы подключены из 2 мест, если хотите отключить 1го клиента пошлите мне цифру 1. И ссылку дает сюда на подробности www.aim.com/im_routing
Насчет отправки все работает: если посылаешь кому то то на втором клиенте естесвенно исходящее не появляется, но входящие приходят сразу на оба клиента, но как не прочитанное…
P.S. клиенты Adium и Qip mobile
Насчет отправки все работает: если посылаешь кому то то на втором клиенте естесвенно исходящее не появляется, но входящие приходят сразу на оба клиента, но как не прочитанное…
P.S. клиенты Adium и Qip mobile
по уму нужно бы сделать или полное дублирование, как в скайпе, или хотя бы настройку: то ли юзер хочет дублирование, то ли по последней активности. у гуглтолка был период принятия решения. по началу он делал так: слал превое сообщение на оба клиента, а остальные — только на тот, откуда отвечаешь. было не очень удобно. потом они, видимо, подумали и переделали, и теперь всё, что я отвечаю и что мне пишут на компе, я вижу в телефонном клиенте, но уведомления после первой мессаги не вылазят. есть надежда, что ещё немного, и дойдут до правильной схемы, как в скайпе, чтобы и инфа дублировалась и уведомления были везде.
в ХМРР вроде не так, как автор пишет. Когда я проверял, то там брался в расчёт приоритет клиента. ИМХО, довольно удобная идея
Цитата из RFC про случай равных приоритетов клиентов. Надеяться, что они всегда будут разными — значит надеяться на то, что пользователь будет их осознанно менять — значит быть неправым.
хм, а мне идея кажется весьма здравой. Когда вводили этот стандарт, то джаббером пользовались любители, которые старались разобраться что к чему, а не все подряд. Собственно, эта тенденция не сильно поменялась в последнее время, просто впихивание джаббера в такие массовые продукты как ГуглТок, Вконтакт и пр. немного всё поменяло.
Просил включить для моего UIN сие чудо в день публикации статьи — всё осталось как есть. Грустно.
Ура! Я сегодня обнаружил что можно!
Интересный ход конём. Запустил 2 (А и В) аськи, с А написал на другой аккаунт, оттуда ответил, ответ пришёл только на А. Потом написал на тот же другой аккаунт с В, оттуда ответил, ответ пришёл опять только на А.
Довольно странное поведение. Это так и задумано?
Довольно странное поведение. Это так и задумано?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ваш ICQ UIN запущен на другом компьютере? Продолжайте общение на этом!