посмотрите мой последний пост. не считая этого поста.

из того что я понял, то у Вас одноуровневая иерархия функций:
т.е имеется набор изолированных спейсов с функциями, именуемый вами api..
тогда каждая функция имеет условное имя : space.function 
пока так ?

Добавлено @ 00:51

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



Это сообщение отредактировал(а) mes - 24.2.2011, 00:52

так я об этом и говорю.

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

как должна выглядеть реализация? как создаваться? как регистрироваться? и что должно быть навязано?
все! это весь вопрос!

вариант 1.1 :

где, dy::channel (dy::connection) wrapper над сокетом, разрещающий подписку на получение ди_мигрантов.. 



Это сообщение отредактировал(а) mes - 24.2.2011, 00:59

да.


при подключении создается user_context.

это диспетчеризация.
ссылка на distr и должна передаваться в реализацию пользователя.

т.е. как-то так:


пока все понятно?

Это сообщение отредактировал(а) boostcoder - 24.2.2011, 01:00

нахождение диспетчера напрямую в user_context`e вызывает сомнения.. 

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

Это сообщение отредактировал(а) boostcoder - 24.2.2011, 01:04

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

да.


нет. дистрибьютор нужен только для входящих запросов. из user_context`а запросы клиенту отправляются иначе. этот момент я пока тоже упустил.


да. клиент не создает контексты...

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

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

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

но в сервере такой прием(создание/регистрация всех обработчиков при создании контекста) кажется логичным.

Это сообщение отредактировал(а) boostcoder - 24.2.2011, 01:28

я соотносил не клиент - сервер, a  клиент - user_context...
на клиентской стороне, создателем клиентов, выступает сам юзер, запускающий программу..
а на серверной стороне, для автоматизации это процесса, выступает сервер.. 

представил..


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


какое отношение это аpi имеет к серверу ?! 


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


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


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


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

Добавлено через 2 минуты и 56 секунд
и опять же позволю себе заметить, что вы смешиваете в кучу понятия из разных, хотя и смежных, категорий :
"клиент/серверное взаимодействие" и "удаленный вызов"

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


я имел ввиду то, что класс окна диалога и служит обработчиком.



очень даже возможно. расскажите свое виденье.


Это сообщение отредактировал(а) boostcoder - 24.2.2011, 02:01

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

клиент -серверное взаимодействие, клиентская сторона  : 
создается объект сессия, который хранит tcp_канал, и является главным контроллером, и допустим состоит из sub_контроллеров..
каждый контроллер включает в себя "входящие" и "исходящие" методы по одной "теме"..
при вызове "исходящего" отправляется импульс в канал, и, если нужно, отражается на форме.. 
при получении "входящего" сессия (точнее ее диспетчер) по имени (префиксу) определяет назначение и делегирует нужному контроллеру..
(может даже создать если его нет), который обрабатывает импульс и также,если нужно, отображает на форме..


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

можно пример использования?


т.е. когда клиент делает удаленный вызов?

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

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

или я все не правильно понял?

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


  

Это сообщение отредактировал(а) mes - 24.2.2011, 10:06