Здравствуйте, Аноним, Вы писали:

E>>Зачем писать на SObjectizer алгоритм работы 2-х кэшей? Для имитационного моделирования? Если так, то про какую оптимальность доставки сообщений может идти речь?
А>Тут надо понимать некоторую аналогию — кеши — это два зеркала в интеренета, например (опять аналогия из жизни). и требуется обеспечить синхронизацию между ними.

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

А>Верно не факт, что идея из hardware, что должна становиться догмой в software, но надо ее знать, чтобы знать, чем идея в software лучше. А то вот я написал HelloWord на SObjectizer, если бы я не знаю другие языки, я бы сказал — круто (серое вещество не работает). А так я начинаю сравнивать со всеми другими языками на автомате и оценивать его возможности.

Мысль, вероятно правильная, но вот аналогия, имхо, не очень
Оценивать язык программирования на основании внешнего вида примера HelloWorld -- это весьма наивно.
К тому же SObjectizer -- это не язык программирования. Это инструмент, который в данное время предназначен для одного (и только одного) языка. Так что, если уж его сравнивать, что с чем нибудь подобным. А то ведь можно пытаться сравнить детектив и пиво, т.к. они являются средством времяпрепровождения.

И давайте взглянем на этот вопрос с другой стороны. Есть читатели, которые, как говорится, "в теме". Они могут сравнить SObjectizer, к примеру с Erlang или с SWITCH. Но ведь это очень специфическая область, про которые не так уж много читателей знают. Для кого-то может стать вообще откровением, что подобный инструмент существует (как для меня существование Erlang в свое время). Этот кто-то может примерить SObjectizer к своей задаче. А кто-то может заинтересоваться данной темой и пойти искать аналогичные инструменты.

Да и если пробовать составить впечатление о программировании на SObjectizer, то лучше делать это не на HelloWorld, а на более сложных примерах. Скажем, на high_traffic/server.cpp и high_traffic/client.cpp.

А>Могу предложить так же реализовать обработку ответа от агента: перегружен, поставил в очередь, такое сообщение уже существует. А так же некоторые сервисы агента — уведодомление о доставке, проверка статуса сообщения.

Ну вот, видите, сколько сразу предложений возникло. Для этого SObjectizer и выносится на обозрение.
Вот вам, к примеру, такая функциональность кажется полезной. А вот мне -- нет, т.к. я считаю, что подобные вещи делают связь между агентами более жесткой. Что приведет к проблемам масштабирования приложения, когда часть агентов потребуется переместить в другой процесс на другой узел сети. Вот у меня такое зашоренное мнение. И было бы интересно услышать контраргументы.

E>>Хочется сохранить разумный баланс между функциональностью SObjectizer и сложностью его реализации. Чтобы не превратить SObjectizer в барахолку неиспользуемых возможностей, которую очень трудно сопровождать.
А>А это уже вопрос архитектуры, разделения проекта на функциональные части, огранизации производства. 2-3 человека это сопросождать не смогут 100%.

Угу. А еще вопрос целесообразности производства

_>>>У людей в белых халатах из Research-центров всегда есть куча идей и куча денег — нет времени это все реализовать.

А>Отлично, осталось только добавить, то что нужно вам. А что добавлять должны решать как минимум 3 человека

Вот как раз третьего и не хватает
Так что, можно сказать, озираемся по сторонам и спрашиваем у окружающих: "Третьим будешь?"