Вы о регистрации реализаций говорите?(наверное реализации Вы и называете агентами, так?)

ну например рассмотреть техподдержку какой нибудь фирмы.. у них на "одном" телефоне сидит куча разных специалистов, _каждый_ по своей области.. каждый является агентом услуги.. т.е один сервис разбит на несколько разделов, каждый из которых представлен агентом..
точно также и для клиента.. есть шеф и у него есть много агентов, _каждый_ по своей специализации..

_каждый_ выделен, так как может быть несколько одинаков специалистов на одну задачу..

Добавлено через 2 минуты и 9 секунд
если применительно к вашей задаче, то есть 
агент авторизации, агент чата, агент приглашений,, агент игры и т.д.. 
все вместе представляют клиента (для серверной стороны может быть аналогично) ..

Добавлено через 4 минуты и 42 секунды

это если сервер все в одном флаконе.. а так он может осуществлять только распределение и на каждое "действие" будет свой сервис..
тогда агент в принципе "равен" сервису..

Добавлено через 5 минут и 42 секунды
грубо говоря логически законченная "единица связи" 

вот малюсенький пример:
для регистрации, нам нужно определить следующее: 1)свободен ли ник, 2)свободна ли почта, 3)если введен бонус-код - определить, валиден ли он.

из этого имеем:


собственно я все это дело вижу так..

вот набросал вид :


Добавлено @ 02:56

т.е соотношение 1:1 на одно апи свое окно.. а если захочется в одном окне показывать сведения получаемые из разных апи ?
или часть апи в одном окне, а часть в другом ?

Добавлено через 4 минуты и 16 секунд
к тому же там только получение, а где отправка ?

Добавлено через 6 минут и 46 секунд
к тому же у вас в схеме прямая завязка на сеть.. т.е что видим , то и пишем и никакой обработки .. 


Это сообщение отредактировал(а) mes - 2.12.2010, 02:57

я это вижу как класс с методами.
кстати в моей начальной версии discoly так все и реализовано. есть class_id и есть method_id.

Добавлено @ 03:06

нет-нет. это код клиентской части. методы on_nick_entered() и on_email_entered() вызываются из гуя. посылка самих команд на сервер происходит посредством интерфейса к классу registration_api _reg.
тут я привел класс registration_api только чтоб было видно его методы. на самом деле его реализация живет на сервере.

Добавлено через 7 минут и 28 секунд

так:



Это сообщение отредактировал(а) boostcoder - 2.12.2010, 03:08

я не имел ввиду непосредственно посылку.. любой диалог состоит из двух частей зачастую не симетричных, высказывание и выслушивание..
ну высказывание у вас есть, а как с получением ? (я в верху отправку с получением перепутал )

Добавлено @ 03:11
а увидел, Вы опять привели все к синхроному виду.. (ночь видать сказывается, не сразу въехал)

Добавлено @ 03:14
т.е. пока ответ на одно сообщение не придет, весь гуй будет ждать.. (ну перерисовку допустим разгрузите),
а вот логику уже без костылей не получится разгрузить.. 
т.е если вы нажали на одну кнопку, на вторую жать бесмыслено пока первая не закончит работу..


Это сообщение отредактировал(а) mes - 2.12.2010, 03:15

не в этом даже дело. в данном примере удобно использовать синхронные вызовы.
другое дело обновление статистики в гуе, оно точно асинхронное...как и множество другого взаимодействия..

поверьте, для гуя не удобно.. 

Вы очень категорично на это реагируете.
я проводил тесты.
к примеру, в 1мбитном канале в мир(разгруженном), время отклика составляет 17-22мс. Вы даже не заметите тормоза.
в этом же канале, при закачке торрента, когда канал нагружен на 100%, время отклика составляет 82-112мс. а это, Вы считаете много?

Добавлено через 3 минуты и 33 секунды
я считаю, что тормоза в 200мс можно вообще не рассматривать как тормоза. если это конечно не реалтаймовская стрелялка  

время отклика зависит не только от ширины канала.. связь не у всех хорошая.. к тому же я говорил о логике представления..
и в частности если в момент замирания при синхронном вызове придет другое сообщение, что с ним делать ?!

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

Добавлено через 1 минуту и 27 секунд

т.к. у нас сетевая часть асинхронная, это сообщение повиснет на диспетчере до тех пор, пока предыдущее не вернет управление.

Добавлено через 3 минуты и 12 секунд
mes, повторюсь: это не проблема/недостаток discoly. это возможность. если пользователь хочет использовать синхронные вызовы - пусть использует. это его личное дело, ровно как и последствия его.

послали msg1 wdem re_msg1.. но пришли re_msg2 и за ним re_msg3 ..
что с ними делать ? пока мы их не заберем из асио, мы не узнаем о re_msg1..a если заберем , то кому отдавать ? можно конечно заpostить в оконный цикл, но.. а вдруг от re_msg3 зависит обработка re_msg1..  ну к примеру re_msg3 это quit, ban или просто дисконнект..

Добавлено через 1 минуту и 36 секунд

ну если эта не нужная нам подробность, то зачем такой пример приводили ?   

Добавлено через 7 минут и 36 секунд

смотря как вы его представляете.. возможны различные реализации.. 



Это сообщение отредактировал(а) mes - 2.12.2010, 03:38

я понимаю о чем Вы. но это не относится к discoly. это полностью ответственность/обязанность пользователя спроектировавшего свою логику.


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

насчет отклика.. вспомните любой сайт отмечающий правильностей полей ввода..
он делает это не после ввода, а паралельно ему.. да возьмите тот же самый гугль..

ну а вобще это делается так : окна синхроно берут из общего контекста нужную им информацию,
приходящие из клиента ассинхронные команды формируют состояние контекста 
и если оно "значительно" изменилась сообщают окнам об обновлении..

Добавлено через 1 минуту и 48 секунд

как не относится если в вашем случае это инструмент дисколи ?... при том низкого уровня..

вот так, влоб: владеет он: 1)registration_api, 2)authorization_api, 3)user_statistic_api, 4)top_statistic_api, 5)news_api, 6)games_list_api, 7)tournament_list_api 8)database_connection.
и все эти объекты создаются при коннекте юзера. вне завсимости от того, когда он будет вызывать их методы(если вообще будет).

можно конечно создавать объекты прям в вызываемых методах.. но это как-то не правильно..