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


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

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

не только..

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

  

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


На мой взгляд Вы все свели к одному частному случаю.. 


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

Добавлено через 9 минут и 42 секунды
в общем что я вижу - это не distributed communication, a простой remote call, так еще и вся ответственность на порограммисте.. 

mes, объясните пожалуйста (концептуально, без кода), чем по Вашему отличается distributed communication от remote call. И как устанавливать удаленное взаимодействие без ответственности программиста 

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

ура у нас гости 


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


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


  


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


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


 , типа того .. 

mes, опишите словами, как Вы представляете инициализацию узлов? и кто такой узел, не считая реализации и вызова? т.е. что это за сущность.

Это сообщение отредактировал(а) boostcoder - 30.3.2011, 12:11

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


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

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

как Вы представляете информировать узлы о существовании других узлов?

aa. ну так это уровень выше.. далеко не всегда нужна такая информированность, а если и нужна то зависит от модели взаимодействия.. 

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

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

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

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

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

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

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

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

какие операции? в смысле, что мы с этого имеем?

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


было бы хорошо.. 


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


групповую обработку сообщений, 
1. например каждая игра имеет метод make_move, но тип аргументов может разниться... 
по имени сервиса можно узнать какой именно тип имеет сообщение и передать нужному контроллеру.. 
2. на основе групп сообщений публиковать интерфейсы
3. ..


Boost Graph Library ?

Добавлено через 1 минуту и 21 секунду
Основная проблема в том что нет хорошей литературы по этой теме, или может я просто не там ее ищу 

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

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

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

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

я кстати понял чего я вчера не мог объяснить.. 
возьмем с++ : есть функция как механизм и интерфейс (ОО) как протокол взаимодействия, при этом последний зависит от задачи.. 

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

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

неплохо бы с этого начать. хотя бы определить сферу применения


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


да


вообще мне крайне редко приходится писать программы, использующие коммуникацию, но примеры привести могу:
1. при взаимодействии веб-клиента (естественно, умеющего javascript) с сервером просто и естественно использовать JSON over HttpRequest
2. SOAP. страшный монстр, куча недостатков, но дело свое знает
3. DCOM. еще страшнее, но при использовании соответствующих инструментов (их есть у нас благодаря Microsoft) довольно удобен.

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


код является целью? я думал целью является решение какой-то задачи... 

Добавлено через 2 минуты и 15 секунд
boostcoder, опишите плиз (еще раз?) первоначальную задачу, которую Вы решаете. В связи с которой и возникла эта тема

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

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

вот и я о том же.


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


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