mes, добрый день Вам.
переделал под буст.сигналы: http://liveworkspace.org/code/b3651455d4b6...4807191b70c2e3a
гляньте плиз. я ничего не накосячил  

далее..
у разработчика игры узнал по поводу толстого/тонкого клиента. все правильно. клиент тонкий.

далее...

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

Добавлено через 5 минут и 29 секунд
Вы случаем не в курсе, как биндить перегруженные функции?
http://liveworkspace.org/code/3415a6646b7c...431f41eb08e4071

так: http://liveworkspace.org/code/1eb478dd937b...3578765f314ffe0

вроде все так , с учетом того что вместо воид* пакет.. 


это можно будет разгружать через шаблонную функцию.. для удобства 

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

ну юзер контекст может предоставлять несколько сервисов..
ну уже известные нам auth, ping 
так же game, как целевой сервис
возможно чат - как дополнительный..

если разделить на контролы, то легко будет добавить новый сервис не затрагивая другие..

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

ага, путем указания нужного типа.. 

вроде назрел очередной вопрос:
т.к. при декларации обработчиков хочется использовать такой синтаксис:

метагенератору, из списка аргументов нужно будет сгенерить структуру. имя структуре он должен назначать сам. далее..он должен сгенерить класс с этими методами. далее..он должен сгенерить junction(по текущей реализации) и все что в нем. вот только я не у верен в том, как структуру разобрать на члены и передать их сигналу(строка 36 в последнем коде)? ведь класс invoker у нас не генерируемый.

какие есть варианты?

Добавлено @ 13:23

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

Это сообщение отредактировал(а) boostcoder - 4.11.2010, 13:23

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

я могу представить конечный исход метагенерации. т.е. в каком виде хочется это видеть.
что именно Вы хотите сказать?

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

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

а как Вы это представляете?


ок.
что сейчас нужно реализовать, зная цель?

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

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

испытание.. такое как например у нас было с ресиверов, в конце которого пришли к сигналам.. 

решил таким способом: http://liveworkspace.org/code/1ffbd8a94c5b...b7ad11428bdb159

сейчас хочу реализовать возможность возврата вызывающей стороне, результат, возвращаемого методом.
т.е. если сигнатура такая: "void type3::fn(...)", чтоб не сериализовать и не отсылать всякий хлам.

есть предложения?



смотрите этот код. т.к. сетевое взаимодействие нам не интересно.

дело не в сети, а в сформулированных требованиях к этому слою.. у меня их нет 

Добавлено @ 19:10

не понял смысла предложения..

Добавлено @ 19:21

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

и насколько я понимаю, то что вы делаете есть в fusion::invoke..



Это сообщение отредактировал(а) mes - 4.11.2010, 19:22

ну вот смотрите..
Вы - клиент.
вызываете метод сервера:

т.е. посылается команда..ожидаете ответа..получаете ответ.

а теперь такой пример:

этот вызов возвращает void. зачем серверу что-то отсылать обратно?

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

он выполнит f() для каждого типа из seq.

мы никогда не ожидаем ответа.. 
клиент вызывает удаленные методы сервера, сервер -  удаленные методы клиента..
ответа как такого нет..

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

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

это серверу решать (в соответсвии с протоколом) будет ли он что отсылать или нет.. 



Это сообщение отредактировал(а) mes - 4.11.2010, 20:04

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

этим и хороша ассинхронность