 |  | | Re: Подобие многоканального телефона. Для ICQ транспорта. |
|  |
 Posted: Fri Mar 23, 2007 1:52 am |
 |
|
| leksey |
| Графоман |
 |
|
| Joined: 17 Dec 2004 |
| Posts: 1909 |
| Location: Москва, Тушино |
|
|
|
|
 |
|
| oss wrote: | Извиняюсь, если уже существует данная тема, но я не смог её найти при помощи поиска. :)
Можно ли с помощю Джаббера сделать подобие многоканального телефона. Т.е. существует один ICQ номер на который пишут несколько людей и соответственно каждое сообщение переадресовывается отдельному оператору у которого стоит джаббер клиент. т.е. необходимо поддержка сессий, в течениии которых людей нельзя переключать на другого оператора. Слышал что существует такое решение для джаббера, но хотелось бы сделать данную вещь не ограничевая людей в выборе протокола или хотя бы ограничить некоторым количеством протоколов, на которых возможна реализация такой системы. |
Чем-нибудь кончилоь начинание? Поделись, пожалуйста.
Я прихожу к выводу, что штука нужная и по одной из работ есть в нем потребность. |
|
|
|
|
| | | Re: Подобие многоканального телефона. Для ICQ транспорта. |
| |
| Posted: Fri Mar 23, 2007 8:55 am |
|
|
| feez |
| Разработчик |
|
|
| Joined: 01 Jan 1970 |
| Posts: 146 |
|
|
|
|
|
|
|
| leksey wrote: |
Я прихожу к выводу, что штука нужная и по одной из работ есть в нем потребность. |
Я постепенно тоже :)
Помнишь мы говорили о том, чтобы сделать на вики набор задач, которые надо реализовать в "коробке" для предприятий. Эта задача, думаю, там должна быть на первом месте. Можно там же оформить и ТЗ по ней, а попозже возможно займусь, если oss не сделал уже :) |
|
|
|
|
| | | Re: Подобие многоканального телефона. Для ICQ транспорта. |
| |
| Posted: Fri Mar 23, 2007 2:29 pm |
|
|
| leksey |
| Графоман |
|
|
| Joined: 17 Dec 2004 |
| Posts: 1909 |
| Location: Москва, Тушино |
|
|
|
|
|
|
| feez wrote: | | leksey wrote: |
Я прихожу к выводу, что штука нужная и по одной из работ есть в нем потребность. |
Я постепенно тоже :)
Помнишь мы говорили о том, чтобы сделать на вики набор задач, которые надо реализовать в "коробке" для предприятий. Эта задача, думаю, там должна быть на первом месте. Можно там же оформить и ТЗ по ней, а попозже возможно займусь, если oss не сделал уже :) |
Про starter kit помню, но вряд ли могу пойти дальше написать какого-то драфта. С другой стороны штукенция эта важная. Собирать лего и допиливать его напильником любимое занятие никсоидов, но порой у них нет на это достаточного времени. Создам как я пока пустую темку на эту темку, может какая там жизнь и зародится.
Теперь по теме.
Ковырял части решение на базе Спарка (читал их доки), пока понял немного. Одно вижу, что оно суется через веб, нужен их клиент и их же сервер. Оно кому такое надо? |
|
|
|
|
| | |
| Posted: Fri May 11, 2007 4:30 pm |
|
|
| leksey |
| Графоман |
|
|
| Joined: 17 Dec 2004 |
| Posts: 1909 |
| Location: Москва, Тушино |
|
|
|
|
|
|
Короче. Необходимость в такой штуке назрела и уже перезрела.
Будем готовить ТЗ и потом реализовывать по возможности, используя частично готовые наработки. |
|
|
|
|
| | |
| Posted: Mon May 14, 2007 9:58 am |
|
|
| feez |
| Разработчик |
|
|
| Joined: 01 Jan 1970 |
| Posts: 146 |
|
|
|
|
|
|
|
Пока такая архитектура назрела.
Абстрактно:
1. Рабочая группа поддержки - это несколько сотрудников имеющих общий представительский адрес в джаббере, других IM сетях и чат-интерфейс в вебе.
2. Когда пользователь (клиент компании) пишет на этот адрес свой вопрос, начинается процесс поиска свободного сотрудника.
3. Каждому свободному (не участвует в других диалогах поддержки) сотруднику, который в онлайне (через ростер) отправляется запрос с вопросом клиента. В это время клиенту светится "ожидайте" или свободных сотрудников нет.
3. Если он соглашается, то создается общая комната, в которую заходит сотрудник и клиент и, пусть, справочный бот, с базой часто задаваемых вопросов. В неё можно приглашать других сотрудников.
4. Начинается диалог, история записывается в базу, чтобы потом можно было поднять и посмотреть/проверить/посмеятся. |
|
|
|
|
| | |
| Posted: Mon May 14, 2007 10:12 am |
|
|
| feez |
| Разработчик |
|
|
| Joined: 01 Jan 1970 |
| Posts: 146 |
|
|
|
|
|
|
|
И возникшие проблемы:
1. К пункту 3. В чат должен входить клиент или промежуточный бот, через которого клиент будет общаться с сотрудниками.
Во втором варианте следующие плюсы: Промежуточный
бот сможет обеспечивать фильтрацию информации, которая видна клиенту, обеспечивает еще один уровень абстракции (не надо в вебинтерфейсе реализовывать поддержку групчатов) и т.д. В общем фильтр. Сможет писать историю -- не надо переделывать muc транспорт.
2. Пока придумал две схемы реализации:
(I) Одна рабочая группа - один бот. Сотрудники в ростере бота.
(II) транспорт рабочих групп.
Проблема первой схемы -- нельзя узнать действительно ли сотрудник свободен, если он зачислен в несколько рабочих групп, без обеспечения взаимодействия между ботами.
Плюсы первой схемы -- независимость от сервера => легче установка.
Со второй схемой у меня темные места: как быть с транспортами в другие сети, в которых надо регистрировать рабочие группы? Насколько сложно реализовать часть-прослойку, которая будет заходить в чаты?
В общем я не могу объективно сравнить две схемы, так как не писал транспорты и не знаю насколько сложно реализовать перечисленные задачи :) |
|
|
|
|
| | |
| Posted: Mon May 14, 2007 11:13 am |
|
|
| Alek |
| Отметившийся |
 |
|
| Joined: 01 Dec 2006 |
| Posts: 15 |
| Location: Belgorod, Russia |
|
|
|
|
|
|
Вещь нужная! поддерживаю.
по поводу свободности, можно определять по idle time или по статусу: свободен для разговора, и сооветсвено меняющийся статус dnd... |
|
_________________
SY, Alek | 2:5037/0 |
|
|
|
| Posted: Tue May 15, 2007 10:36 am |
|
|
| feez |
| Разработчик |
|
|
| Joined: 01 Jan 1970 |
| Posts: 146 |
|
|
|
|
|
|
|
| Между ботом и транспортом выбор сделан: после долгого втыкания в twisted и в zope.interfaces назрела схема, с помощью котороый можно абстрагировать логику и сделать возможность запустить программу и как бота и как транспорт. В режиме бота создается один экземпляр логики, а в режиме транспорта много :) |
|
|
|
|
| Posted: Tue May 15, 2007 4:11 pm |
|
|
| leksey |
| Графоман |
|
|
| Joined: 17 Dec 2004 |
| Posts: 1909 |
| Location: Москва, Тушино |
|
|
|
|
|
|
| Alek wrote: | Вещь нужная! поддерживаю.
по поводу свободности, можно определять по idle time или по статусу: свободен для разговора, и сооветсвено меняющийся статус dnd... |
Мне больше нравится ручной вариант с Check in и check out. То что ты предлагаешь, то скорее второй уровень. Как из 10 операторов выбрать одного конкретного либо же сформировать нескольких операторов, между которыми делать выбор. |
|
|
|
|
| | |
| Posted: Tue May 15, 2007 4:14 pm |
|
|
|
| leksey wrote: | | Alek wrote: | Вещь нужная! поддерживаю.
по поводу свободности, можно определять по idle time или по статусу: свободен для разговора, и сооветсвено меняющийся статус dnd... |
Мне больше нравится ручной вариант с Check in и check out. То что ты предлагаешь, то скорее второй уровень. Как из 10 операторов выбрать одного конкретного либо же сформировать нескольких операторов, между которыми делать выбор. |
из 10 (к примеру), операторов выбрать любого свободного... зачем усложнять? |
|
|
|
|
| | |
| Posted: Wed May 16, 2007 6:57 am |
|
|
| coolkaas |
| Бывалый Жабовод |
 |
|
| Joined: 23 Mar 2007 |
| Posts: 51 |
| Location: Пенза |
|
|
|
|
|
|
вставлю свои 10 коп.:
ручной вариант чем выгоден: например системы, где познания разных операторов различны и есть свои предпочтения -- тогда если "тематический" оператор свободен, он берёт на себя общение, если он занят (это должны видеть другие?) -- то они, как менее знающие какой-то тонкий вопрос (но тем не менее, представляющие предметную область), берут клиента на себя, "прикрывая амбразуру". Или в конце концов, по таймауту, если никто ручками не соизволил взять клиента, происходит автоматическое назначение оператора.
Наверно будут востребованы и ручные и автоматические варианты раздачи Оператора Клиенту, в зависимости от специфики системы. (но закладывать это в систему, имхо, надо сразу, пусть пока и на уровне "заглушки"). |
|
|
|
|
| | |
| Posted: Wed May 16, 2007 7:21 am |
|
|
| feez |
| Разработчик |
|
|
| Joined: 01 Jan 1970 |
| Posts: 146 |
|
|
|
|
|
|
|
| coolkaas wrote: | вставлю свои 10 коп.:
ручной вариант чем выгоден: например системы, где познания разных операторов различны и есть свои предпочтения -- тогда если "тематический" оператор свободен |
А как будет определятся тема, чтобы найти наилучшего оператора?
Я немного не понял, что такое ручная раздача и Check in и check out.
Пока я понял, что надо операторов разбивать на группы и сначала проверять операторов из первой группы, потом второй и т.д. Также то, что оператор должен иметь возможность отказаться.
Кстати вы пробовали qunu? У меня был примерно такой же план:
1. Выбираются свободные операторы. (по статусу и чтобы не было других чатов)
2. Каждому свободному по очереди отправляется приглашение с таймаутом до тех пор, пока кто-нибудь не согласится. |
|
|
|
|
| | |
| Posted: Wed May 16, 2007 7:40 am |
|
|
| coolkaas |
| Бывалый Жабовод |
|
|
| Joined: 23 Mar 2007 |
| Posts: 51 |
| Location: Пенза |
|
|
|
|
|
|
я тоже не знаю, что такое "ручная раздача", я просто подключился к беседе на данном абстрактном уровне, обсуждая удобство использования.
Кстати, не факт, что если у Оператора есть чаты -- он не сможет вести еще 1-2 чата "своей" тематики.
И еще я не понял. зачем нужны группы.. По-моему, излишнее накручивание.
| Quote: | | по очереди отправляется приглашение с таймаутом до тех пор, пока кто-нибудь не согласится |
Это сколько ж Клиенту ждать придётся в итоге? 
А еще мысль -- хорошо бы уметь "переводить" разговор на другого Оператора, скажем: хватает Клиента любой, выясняет специфику. а потом "форвардит" на более подкованного в данной области.
(Прошу учесть, что мои мысли абстрактны и оторваны от реализации в конкретных протоколах, я просто рассуждаю об удобстве). И ессно, если все Операторы одноранговы по знанию/возможности_помочь -- то всё вышесказанное надуманно, костяк для одноранговых и взаимозаменяемых Операторов уже достаточный. имхо. |
|
|
|
|
| | |
| Posted: Wed May 16, 2007 8:17 am |
|
|
| feez |
| Разработчик |
|
|
| Joined: 01 Jan 1970 |
| Posts: 146 |
|
|
|
|
|
|
|
| coolkaas wrote: | | Кстати, не факт, что если у Оператора есть чаты -- он не сможет вести еще 1-2 чата "своей" тематики. |
Крутилку "максимум одновременных чатов" предусмотрим %)
| coolkaas wrote: | | И еще я не понял. зачем нужны группы.. По-моему, излишнее накручивание. |
Чтобы была возможность отделить тех, кого стоит дергать только тогда, когда уже все в пред. группе заняты. Возможно никому и не понадобится, но предусмотреть надо ...
| coolkaas wrote: | | Quote: | | по очереди отправляется приглашение с таймаутом до тех пор, пока кто-нибудь не согласится |
Это сколько ж Клиенту ждать придётся в итоге? :) |
Некоторое время %) А как это можно ускорить?
| coolkaas wrote: | | А еще мысль -- хорошо бы уметь "переводить" разговор на другого Оператора, скажем |
Понятно. В планах было, что общение будет происходить в MUC-е, следовательно там может быть сколько угодно операторов одновременно. Надо только понаприглашать :)
| coolkaas wrote: | | И ессно, если все Операторы одноранговы по знанию/возможности_помочь -- то всё вышесказанное надуманно, костяк для одноранговых и взаимозаменяемых Операторов уже достаточный. имхо. |
Все правильно, надо сейчас расмотреть как можно больше вариантов применений и попытаться представить в деталях, как это будет происходить со стороны оператора, со стороны пользователя, со стороны админа (который назначает операторов). |
|
|
|
|
| | |
| Posted: Wed May 16, 2007 8:47 am |
|
|
| coolkaas |
| Бывалый Жабовод |
|
|
| Joined: 23 Mar 2007 |
| Posts: 51 |
| Location: Пенза |
|
|
|
|
|
|
Таки не до конца понял про Группы.. Они жёстко назначаемые? серия групп, читай Списков -- в некоей "первой", как ты называешь, перечислены самые дёргаемые юзеры, потом более важные, занятые -- как только незанятых юзеров из первой группы больше нет -- задействуется список "номер два", по исчерпании его -- "номер три", так? Еще смежная мысль -- автоматическое переведение Операторов из одной группы в другую, по тому или иному признаку, описанному в некоем правиле-правилах..
И вообще, интересный вариант нарисовался: все в каких-то группах-списках.. И между группами задано некоторое взаимодействие. Причём возможно создание врЕменных списков, например, участников текущих муков.
Т.е., есть группа Оффлайн, есть Онлайн, некоторые члены группы Онлайн могуть и членами временно созданной группы Чат_с_Клиентом1. Хотя группа Чат_с_Клиентом1 может иметь в названии модификатор типа: Чат_с_Клиентом1_(Заправка_картриджа_HP1100A) -- с другой стороны, мук может иметь штатную тему, сначала дефолтную, а потом, по желанию Оператора(ов) меняемую на конкретную -- мож обсуждение затягивается, и свободные Операторы желают самочинно подключаться к разговорам. А админ все эти списки-группы видит и знает что и где кто делает. И повелевает. Только отображение списков как-то фигово ложится в херы и их отображение, без наворачивания специального софта. Такой вот концепт..
А насчёт "ждать клиенту", я имел ввиду, что незачем отправлять сообщение приглашения с таймаутом "по очереди", проще и быстрей всем сразу. Хотя кому-то, безусловно, и вариант "по очереди" понадобится. |
|
|
|
|
| | |
|
