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

десктоп:
— кроссплатформенное приложение
— еще более нагруженный ГУИ, очень кастомный, может, с подключением Open GL. Для примера вообще можно взять Windows Expressions (особенно учесть непосредственно холст с большим количеством элементов)

вопросы:
1. язык, стек технологий для разработки
2. целесообразность написания общего ядра на одной кодовой базе (или 2 реализации). Дело в том, что в корне функционал одинаковый, различны лишь надстройки. Продукты работают параллельно (что-то вроде, как office & office 360)

Варианты языков, которые пока рассматриваются:
1. C++ + Python, Qt
2. Java, SWT

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

у команды опыт С/C++, Python, PHP. Но расширить кругозор/команду есть возможность. т.е. нужно выбрать "правильный вариант", при котором будет гибкое, более быстрое решение

C++ + Python, Qt

Ядро на C++ и Qt. Desktop приложение на нем же. Серер на питоне (twisted + по вкусу) + расширение для питона на С, которое позволяет использовать C++ и Qt ядро.

Здравствуйте, Eye of Hell, Вы писали:

EOH>

C++ + Python, Qt

EOH>Ядро на C++ и Qt. Desktop приложение на нем же. Серер на питоне (twisted + по вкусу) + расширение для питона на С, которое позволяет использовать C++ и Qt ядро.

Почему не java? какие преимущества?
+учесть тот факт, что ядро будет только на сервере, будет обычный клиент-сервер..

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

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

А>десктоп:
А>- кроссплатформенное приложение
А>- еще более нагруженный ГУИ, очень кастомный, может, с подключением Open GL. Для примера вообще можно взять Windows Expressions (особенно учесть непосредственно холст с большим количеством элементов)

А>вопросы:
А>1. язык, стек технологий для разработки
А>2. целесообразность написания общего ядра на одной кодовой базе (или 2 реализации). Дело в том, что в корне функционал одинаковый, различны лишь надстройки. Продукты работают параллельно (что-то вроде, как office & office 360)

А>Варианты языков, которые пока рассматриваются:
А>1. C++ + Python, Qt
А>2. Java, SWT

А>Если есть люди, которые сталкивались с такими задачами, интересуют рекомендации. истории успеха, литература, которую имеет смысл почитать

А>у команды опыт С/C++, Python, PHP. Но расширить кругозор/команду есть возможность. т.е. нужно выбрать "правильный вариант", при котором будет гибкое, более быстрое решение
Взгляните на Google Native client.
+ работает в любом браузере
— надо убедить пользователя поставить это расширение

Почему не java? какие преимущества?

Никаких преимуществ. рекомендация основана на:

у команды опыт С/C++, Python, PHP

+учесть тот факт, что ядро будет только на сервере, будет обычный клиент-сервер.

Не понял смысла этой фразы.

Здравствуйте, Eye of Hell, Вы писали:

EOH>

Почему не java? какие преимущества?

EOH>Никаких преимуществ. рекомендация основана на:

EOH>

у команды опыт С/C++, Python, PHP

тут можно добавить еще C#
и, кстати, какова реальная позиция Mono для вэб-решений? МС активно спонсирует разработку Моно. реально ли создать на баз Моно серьезный сервис под управлением линукс?

EOH>

+учесть тот факт, что ядро будет только на сервере, будет обычный клиент-сервер.

EOH>Не понял смысла этой фразы.
Изначально я писал, что ядро дублируется на сервере и клиенте. сейчас же клиент просто пользуется АПИ сервера. является просто ГУИ с надстройками над сервером..

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

А>Здравствуйте, Eye of Hell, Вы писали:

EOH>>

Почему не java? какие преимущества?

EOH>>Никаких преимуществ. рекомендация основана на:

EOH>>

у команды опыт С/C++, Python, PHP

А>тут можно добавить еще C#
А>и, кстати, какова реальная позиция Mono для вэб-решений? МС активно спонсирует разработку Моно. реально ли создать на баз Моно серьезный сервис под управлением линукс?
Ну ASP.NET поддерживается полностью.
Но серьезный сервис это не столько веб, сколько инфраструктура. Базы данных, сервисы, workflow итп.
На windows это легко, ибо части фреймворка. В Linux хуже, потому что мало кто такое пишет, а в Mono нету.

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

А>привет.
А>2. Java, SWT
Java + (Swing или Flex или HTML). Зачем SWT не понятно.

Проблемы с производительностью решаются за счет горизонтального масштабирования, а в Java все с этим отлично. Начиная от Terracota и заканчивая Hadoop'ом. Это если речь идет о действительно больших нагрузках.

PS ПМСМ, mono это начать разрабатывать на Линукс, а закончить на Windows...

Изначально я писал, что ядро дублируется на сервере и клиенте. сейчас же клиент просто пользуется АПИ сервера. является просто ГУИ с надстройками над сервером..

GUI — desktop или web?

EOH>GUI — desktop или web?
десктоп. десктоп версия является надстройкой над серверной (70% функционала сервера + свои плюшки, которые недоступны на сервере)

LV>Проблемы с производительностью решаются за счет горизонтального масштабирования, а в Java все с этим отлично. Начиная от Terracota и заканчивая Hadoop'ом. Это если речь идет о действительно больших нагрузках.

По некоторым словам в описании Hadoop это то, что использует гугл (MapReduce), если это не название самой технологии в целом.
А есть что почитать на русском по этой теме? хотя бы небольшой пример работы.
При работе, я так понимаю, вводятся понятия задача, очередь задач? но на каком уровне все это происходит?

LV>PS ПМСМ, mono это начать разрабатывать на Линукс, а закончить на Windows...

Если десктоп клиент который по API обращается к серверу — то выбор технологий резко расширяется до "что команда знает, умеет пользоваться и успешно применяла". C++ и Qt для desktop клиента подходят в целом неплохо, но интеграция с RPC слабовата. Если клиент только под винду и команда знает C#, то он с WCF способен сэкономить довольно много времени за счет почти автоматического превращения вызова функции на клиенте в формирование запроса по сети, отправку его на сервер, ожидание результата и его возвращение.

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

А>вопросы:
А>1. язык, стек технологий для разработки
А>2. целесообразность написания общего ядра на одной кодовой базе (или 2 реализации). Дело в том, что в корне функционал одинаковый, различны лишь надстройки. Продукты работают параллельно (что-то вроде, как office & office 360)

А>Варианты языков, которые пока рассматриваются:
А>1. C++ + Python, Qt
А>2. Java, SWT

А>Если есть люди, которые сталкивались с такими задачами, интересуют рекомендации. истории успеха, литература, которую имеет смысл почитать

А>у команды опыт С/C++, Python, PHP. Но расширить кругозор/команду есть возможность. т.е. нужно выбрать "правильный вариант", при котором будет гибкое, более быстрое решение

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