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

допустим конечной точкой я хотел бы видеть такой интерфейс :



он состоит из двух частей.. методов посылающих запросы и гетеров получающих информацию о текущем состоянии..

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




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

это Вы об синхронных вызовах размышляете?

нет... о распределенной интеграции объектов..

Добавлено через 2 минуты и 45 секунд
тогда мы имеем три сущности определяющий наш объект :


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

я даже слов таких не знаю  

попробуем условно связать их : 

где составляющие обладают такими условными связями.. 


при такой схеме agent выступает в роли "верхней точки" -  интерфейса компонента.. 
service - отвечает за логику
result - за предоставление конечного состояния.. 

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

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


в принципе результ будет подобен 




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

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

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

ptcl::.. - некие структуры..

тогда предварительно у нас получается такая картина :


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


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

mes, вот самый минимальный пример: http://code.google.com/p/discoly/source/br...amples/minichat
минимальней некуда  

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

Добавлено через 12 минут и 3 секунды
agent может пользоваться более чем одним сервисом, поэтому remote_service в предыдущем примере является излишним и вместо него должна быть конечная точка, в  которой будем регистрировать нужные результаты.. 


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

сама junction может получаться наследованием от шаблона net_client с указанием списка типов подерживаемого протокола.. 

mes, позвольте прерву Вас ;)
к примеру, если сейчас скомпилить и выполнить клиент и сервер из последнего примера, то когда любой из них отключается, второй сыплет эксепшены. это происходит из-за того, что нет общего механизма обработки отключений, и встроенный сервис ping_service все еще работает. хотя, я реализовал встроенный дисконнект сервис. и он работает. но не разработал общий принцип и последовательность операций при получении команды disconnect.
сейчас это реализованно следующим образом: любой из участников сессии может послать disconnect серверу. так же, сервер тоже может послать disconnect любому участнику.
но не реализована сама последовательность действий выполняемых при disconnect`е. полагаю, когда любой из участников получает от сервера disconnect, должен в ответ послать серверу ответ о том, что он готов отключится. это нужно для того, чтоб он мог выполнить необходимые действия, а не отключится тупо на пол пути. так вот...какие именно действия он должен выполнить - зависит от пользователя протокола. т.к. последовательность_действий - известна реализатору логики.
значит, сам класс net_client не должен знать обо всем этом. ему нужен хендлер, который он должен вызывать при получении disconnect. и по возврату из этого хендлера, он должен отсылать серверу подтверждение disconnect`а.

у сервера логика немного иная...

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

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

mes, насколько я понимаю, Вы сейчас ищите способ уйти от кодогенерации?

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

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

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

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

пропущен "уровень обработки.. " т.е. дырка в абстракции.. 

вот я дятел  
какую нафиг раздельную кодогенерацию я делаю?! ведь к примеру сервер, чтоб использовать интерфейсы пользователя, должен иметь в распоряжении структуры сгенеренные для пользователя!! 

Добавлено через 11 секунд
а наоборот.

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

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