Межпроцессное взаимодействие, числодробилка и веб-интерфес

лучше обойтись без Qt.
задания в БД это хорошо.

Ещё можно сокеты использовать, если требуется онлайн-взаимодействие а не только «помещаешь задания а оно тупо идёт одно за другим исполняет». То есть если понадобится «прервать работу», «приостановить» и тд.

Хм, а зачем вообще разделять? Если веб-интерфейс, то код на сервер просто прямым образом вызывают функцию числодробилки и всё, зачем какое-то взаимодействие устраивать?

Зачем веб-интерфейс на локальной машине? Для локальной рабоы лучше имхо подойдёт совершенно обычный интерфейс. И БД, по-моему, тоже оверкилл. Почему не просто файлы? Хотя, если полноценный клиент-сервер, то да.

Ximen и archimag САПР предполагается использовать на довольно крупных предприятиях, поэтому и возникает такое деление на числодробилку и клиентскую машины из следующих соображений:

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

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

> САПР предполагается использовать на довольно крупных предприятиях,

поэтому и возникает такое деление на числодробилку и клиентскую

машины из следующих соображений

Это я понял, но если будет веб-интерфейс, то будет и веб-сервер (логично?), а раз так, то зачем как-то отделять веб-сервер от «числодробилки» и организовывать между ними какое-то там взаимодействие, если можно и веб-сервер и числодробилку разместить в рамках одного сервера-приложений, на котором они будут взаимодействовать непосредственно?

Qt спасет отца русской демократии =)

Мысль интересная, но написать годный в продакшане веб-сервер просто не возьмусь - сейчас нет таких скилов, а на изучение уйдет много времени - хотелось бы к середине весны иметь рабочий вариант, поэтому и возникла идея «набыдлокодить» на чем-нибудь относительно простом (например на Rails) веб-морду и использовать ее.

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

Проще всего вам оформить «числодробилку» как CGI и обращаться с ней при помощи XMLHttpRequest.

> написать годный в продакшане веб-сервер просто не возьмусь

А это не нужно. Тебе нужно всего ничего - открыть сокет, читать данные, парсить запрос. Мусор выкидывать.

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

На гемморой с рельсами и бд ты потратишь гораздо больше времени.

Угу. а если числодробилка 8 часов работает?

Как их не разделять?

Вот человек загрузил задачу. задача встала в очередь, ему появилось - ожидаемое время когда машина приступит к решению - через 8 часов. ожидаемое время решения - 3 часа.

Проще всего вам оформить «числодробилку» как CGI и обращаться с ней при помощи XMLHttpRequest.

Вполне себе не плохой вариант может быть.

Qt числодробилкой используется только для работы с БД (Postgres), если потратить немного времени, то можно и переписать на «чистом» libpg

А если морда на Qt и общаться просто через TCP-сокет? Не проще ли будет?

Угу. а если числодробилка 8 часов работает?

Как их не разделять?

Сохраняем сессию в cookies, при очередном заходе проверяем, решена ли задача, если решена - отдаем данные, подчищаем мусор (т.е. «числодробилка» вертится как демон, CGI общается с ней хоть через фифо, хоть через именованный канал). Готовые данные, в зависимости от того, сколько их и в каком они виде, можно либо в БД запихивать (тот же mysql), либо сохранять в бинарном файле.

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

рекомендую-таки через веб.

взаимодействие между ними - разумно postgres+tcp.

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

> Угу. а если числодробилка 8 часов работает?

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

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

ибо вместо запроса по фифо проще сделать запрос к базе «select * from задачи where готово=1»

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

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

И даже не думал так думать! Конечно демон. Это и не обсуждается. Я к тому что простую морду на Qt сваять - это дело пяти минут и, возможно, проще, чем веб. Зачем Postgres я как-то не очень понимаю - TCP, вроде, достаточно.

Тоже вариант, учитывая кросплатформенность Qt4, можно обеспечить собираемость клиента под обееми платформами, тем более что наработки по клиенту у меня есть. Но в этом случае надо добавлять к серверу сетевую функциональность, многопоточность, а я стараюсь максимально облегчить его, чтобы не дергать «по пустякам» (вроде результата прошлого расчета). Думаю если идея с веб-мордой не пройдет, именно так и делать - кросплатформенный Qt-клиент

а историю где хранить и права доступа?
проще веб как раз.

делай веб. никого не слушай. если нужно - всё расскажу и подскажу.

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

При таких раскладах предложение vahvarh выглядит оптимальным.

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

делай веб. никого не слушай. если нужно - всё расскажу и подскажу.

Плюсую. Особенно не надо слушать тех, кто советует это <censored> Qt.

Особенно не надо слушать тех, кто советует это <censored> Qt.

Обоснуй.

В итоге получаем такую архитектуру:

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

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

Я правильно понимаю?

Если не брать во внимание мое ИМХО, то: во-первых, на слабых машинах эти Qt будут жутко тормозить (если, конечно, не использовать Qt3 или даже Qt2), во-вторых из-за одного приложения придется устанавливать уйму ненужных библиотек. Можно еще добавить: кросплатформенность будет кривая (хотя мне, честно говоря, на мастдайные компьютеры наплевать).

Ну если вся задача qt - дёргание postgresql то это как-то оверкилл. Хотя впринципе - я сторонник работающих программ а не «политически правильно написанных»

То есть работу числодробилки с базой лучше переписать на «чистой» libpg? Или, по Вашему мнению, допустимо оставить модули QtCore и QtSql?

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

Да не нужна вам графическая морда вообще. У вас же будет веб-интерфейс.

Как будете общаться с базой, зависит от того, что вы выберете. Соответственно, через функции пакета ваша_база-dev и будете к ней обращаться.

А зачем? В печеньках нужно session_id сохранять. Аутенификация по логину-паролю. В базе есть таблица задач с привязкой через user_id. И всё.

во-первых, на слабых машинах эти Qt будут жутко тормозить

Не серьёзно. Таких слабых машин уже давно не существует.

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

Уйму - это сколько? 4?

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

Не замечал как-то...

Если пишешь на плюсах, то лучше используй SOCI, зачем тянуть Qt для работы с базой?

Ну если вся задача qt - дёргание postgresql то это как-то оверкилл

Ну по мне так и веб сервер выглядит оверкилом :) К тому ж ТС вроде сказал, что оно уже для этого используется :)

Хотя впринципе - я сторонник работающих программ а не «политически правильно написанных»

+1. И твоё решение я уже признал более оптимальным.

Спасибо за ссылку! По первому взгляду очень интересная библиотека, буду изучать

Только используй второй вариант и никогда не первый.
Возможно в postgresql будет не :val а ?.

// Example 1.
for (int i = 0; i != 100; ++i)
{
sql << «insert into numbers(value) values(» << i << ")";
}

// Example 2.
for (int i = 0; i != 100; ++i)
{
sql << «insert into numbers(value) values(:val)», use(i);
}